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On (57) Abstract: A resource provider subsystem ("RPS") secuies and combines a universal resource locator (URL) in a web page 
O^ document. The RPS transmits secure URL with resource access right data to a web access device ("WAD") via a network. The WAD 
^ executes a browser a^jplication to display the secure URL. A user of the WAD can activate the secure URL to generate a signal. The 
'^^^ signal includes the secure URL and is transmitted finom the WAD to the resource distribution subsystem ("RDS"). The RDS receives 
2 ^he signal, authenticates the request, and verifies that the resource access right data has not been changed after it was established 
by the RPS. If the request is authenticated and veriBed, the RDS provides the resource to the WAD. The resource can include data. 
O itnage(s), applet(s). and/or a downloadable program module. Alternatively, the fesouice can be a server application optionally 
^ programmed to permit the user of the web access de^ce to interact therewith. Through use of the secure URL, the RPS can control 
^ access to the resource even though it is hosted at distributed sites of a network. 
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BESOURC3E DISTRIBUTION IN NETWORK ENVIRONMENT 

TECHNICAL Field 

This invention is directed to a system for distributing a resource in a network 
enviromn^t for access by users on a restricted basis. The resource can be a computer 

5 program(s), applet(s), text ffle(s), and/or image file(s), for example. Such resources can be 
activated or provided to a user's web access device x^on authentication and validation of a 
request from such user's device. The invention permits a resource to be distributed on a 
limited-access basis in a network environment The invention is also directed to related 
subsystOTis, devices, methods, and articles. 

10 Background Art 

Intemet-based resource providers typically offer data or computer program(s) 
accessible to users via the fiitemet A data resource can include news, information, or 
entertainment in the form of text and^or images. A computer program resource can include 
any software accessible to users via tihie Internet Such computer software can inchide 

15 transaction software for buying or seUing products or services via the Internet, applications 
such as map locators or other software providing an application to IntOTiet users, 

Alfliough some resource providers elect to maintain their own Internet infiastructure 
to host tiie data and/or computer program resource(s) they oflFer fiitemet users, there is an 
increasing trend to outsource some or all hosting of resources to other businesses that 

20 specialize in this activity. There are several reasons why outsourcing' is attractive to a 
resource provider. Acquisition and maintenance of web servers, database servers, firewall 
servers, failovers, related software, and other equipment required to host resources is 
relatively costiy, complex, time-consuming, and requires hiring of skilled persons to build 
and operate the resource-hosting infrastructure. In addition, if a resource provider hosts all 

25 of its resources, it must either build its system c^abilities to svqjport tiie maximum expected 
usage of its resources. The cost, of building the hosting infrastructure to accommodate 
maximum-expected traffic from Internet users is often not justified relative to outsourcing 
some of tiie traffic to an outside hosting service. Hence, a resource provider often has 
compelling reasons to outsource hosting of resources offered its Memet users. 

30 Anoflier fector that resource providers must consider when hosting tiieir resources to 

accommodate user traffic via the Internet pertains to tiie speed of response to users of the 
resource. It has been found that on average Internet users will wait no more than several 
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seconds before moving on to a different website. Hence a resource provider must generally 
ensure adequate Internet iniSrastructure to be su£Biciently responsive to maintain interest of 
Internet uscts. It has been found tiiat response times to Internet users can be significantly 
reduced through flie use of a distributed server environment. In other words, if a resource 
5 provider's hosts its resources on servers strategically distributed in different cities tooughout 
the areas in which the user's are located, response times can be reduced greatly relative to a 
non-distributed server environment For all of the above-listed reasons, distributed server 
environments are being increasingly utilized by resource providers to host resources. 

Distributed server environments operate relatively well if the hosted resource is to be 

10 accessible to Internet users on an imrestricted basis. However, if resource access is to be 
restricted, distributed server environments can be difficult to operate and maintain. For 
example, if a user purchases a subscription to a resource from a provider, the fact that the 
user is authorized to access the resource must be broadcast to aU servers in the distributed 
server system. Hence, a significant amount of data must be transmitted throughout the 

15 distributed server to maintain current records of users permitted to access resources and the 
extent of the permitted access rights. In addition, to enable an operator of a distributed 
server to effectively manage the resource, a significant amount of control over the resource 
must be given to the operator{s) of the distributed server(s). Many resource providers are 
reluctant to allow outside resource hosting operators to have significant control of their 

20 resources. It would be deshrable to overcome these disadvantages of the previous 
technology. 

Bncryption and data security technologies are also relevant to this invention. One 
such' technology is the so-called shared key encryption in which transmitting and receiving 
parties share the same key (e.g., a 128-bit or 256-bit key) use it to acode or decode 

25 messages transmitted via the Internet. Another J5)proach is public key/private key pair in 
which a transmitter of a message uses a public key to encrypt the message, and flie receiver 
uses a private key to decrypt the message. Also related to the invention are hash algorithms 
or message digests algorithms that are used to encode data transmitted over public networks 
such as flie Internet In general, message digest algorithms operate on data of virtually any 

30 length, and generate a fixed-l^gth output termed a digest or hash. A digest has the 
following properties: 
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(1) different data do not map to the same digest upon ^plication of a digest 
algorithm; and 

(2) the digest does not reveal anyfliing about the particular digest algorithm or 
data tiiat was used to generate it. 

5 An example of a digest algorithm is SHA-1 published by the United States Government 
SHA-1 genres a one-hundred-sixty (160) bit hash from any length data string. More 
information on the SHA-1 algorithm is available at http://www.itlJDistgov/fipspubs/fipl80- 
LhttEL Anothea: example of a digest algorithm is MD5 (Message Digest Algorithm 5) 
produced by RSA Laboratories, Inc. The MD5 algorithm can be used to hash a data string of 

10 any length into a one-hundred twenty-eight (128) bit vahie. Another digest algorithm is 
Tiger developed by Anderson and Biham available at Jftp,funetfi:/pub/crypt/hash/tiger. Yet 
another hash algorithm is RIPEMD-160 available at 
http'7/vvww.esatJculeuven.ac.be/'4>osselae/ripemdl60±tnd^ RIPEMD-160 encrypts data of 
any lengfii into a one-hundred sixty (1 60) bit string. 

15 Disclosure of the Invention 

Generally stated, the system, subsystems, q)paratuses, and methods described in this 
document can be used to distribute a resource in a network environment in a manner that can 
be controlled by a resource provider* 

A first disclosed method is characterized by generatmg hash data based on at least 

20 one of a universal resource locator (URL) of a resource, resource access right data defining 
restriction(s) on a web access device (WAD) and/or user thereof to access the resource, and 
an IP address of the WAD. The first method also is characterized by combining the hash 
da t ? , URL> andresomrce access right data, in a web page. The first method can characterize 
transmittuig the web page document including the secure URL to the WAD in response to a 

25 request for the web page document from the WAD. The hash data can be generated using 
key data that is combined with the URL and hashed to generate the hash data. The first 
method can comprise transmitting the key data from a resource provider subsyst^ (RPS) to 
a resource distribution subsystem (EtDS) &at is to host the resource so that, if the secure 
URL is activated by the WAD to gen^ate arequest for the resource to the RDS, the RDS can 

30 verify that the resource access right data has not hem modified other than by the RFS. The 
resource access right data can include at least one of: (1) an authorized Internet protocol (DP) 
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address or IP address range; (2) life-span data indicating die life-span indicating a time 
period over which requests for accessing a resource are vaKd; aad/or (3) maximum reference 
data indicating a maximum number of times a web access device and/or user thereof can 
access a resource. 

A second disclosed me&od comprises, at a resource provider subsystem (RPS), 
receiving a request for a web page fix)m a web access device (WAD) via a networic, and 
detennining resource access right data for the WAD and/or a user thereof The resource 
access right data defines restriction(s) for the WAD and/or user thereof to access a resource. 
The second method also is characterized by securing a universal resource locator (URL) for a 
resource by generating hash data based on the URL and/or resource access right data, and 
combkdng the URJU resource access right data, aad hash data together in the web page. The 
second method further is characterized by transmitting the web page haviug the secure URL 
to the web access device via the network in response to the request received from the WAD. 
The hash data can be generated further using key data corresponding to the WAD and/ or user 
thereof. The method caa further characterize the step of transmitting key data corresponding 
to the web access device and/or user thereof to a resource distribution subsystem (KDS) 
hosting Ae resource so that, if the secure URL is activated by the web access device to 
generate a request for the resource to the RDS, ttie RDS can verify that the resource access 
right data has not been modified other than by the RPS. 

A third disclosed method is characterized by receiving a signal requesting a web page 
document from a web access device (WAD). The signal includes an latemet protocol (JP) 
address of the WAD. The flnrd method also is characterized by retrieving data for the web 
page document including a universal resource locator (URL) of a document referenced in the 
web page document, retrieving resource acc^ right data for the URL nsing the IP address of 
the web access device and/or user name and password established through a log-in 
procedure, and generating hash and/or encrypted data to generate secure resource access right 
data. The third method fWher is charact^ized by c^ 

with the respective URL to generate a secure URL> generating the web page document 
including the secure URL, and transmitting the secure URL to the WAD. 

A fourth disclosed method is characterized by, at a web access device (WAD), 
transmitting a signal requesting a web page document to a resource provider subsystem 
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(RPS), and receiving the web page document having a secure universal resource locator 
(URL) with hash data, XJRU and resource access right data, in response to the request The 
fourth method can also characterize activating the secure URL with the WAD to transmit a 
signal requesting access to a resource designated by the URL to a resource distribution 
5 subsystem (RDS), and accessing the resource with the WAD if the RDS detmnines that 
access to the resource is authorized based on the hash data and resource access right data 
contained in the request signal. 

A fifth disclosed method is characterized by, at a web access device (WAD), 
generating and transmitting a request for a web page document to a resource provider 

10 subsystem (RPS), and receiving the requested web page dociiment having a secure universal 
resource locator (URL) with secured resource access right data from the resource provider 
subsystem (RPS). The fifih method also is characterized by executing a browser appUcation 
and web page document with the WAD to generate and transmit a signal to request a 
T^ource distribution sub^tem (RDS) to provide access to a resource identified by the 

15 secure URL. The request signal can include the URL and secure resource access right data. 
The fifth method further is characterized by, if access to the resource is permitted by the 
RDS, accessing flie resource wifli the WAD. The accessing of the resource can be performed 
in different ways, depending xspon the nature of the resource. For example the accessing of 
the r^ource in the fifth method can characterize substeps of receiving at flie WAD resource 

20 data from the RDS, storing the resource data in memory of the WAD, executing an 
application with the WAD based on the resource data to generate a signal, and generatuig a 
display witti the WAD based on the generated signaL Alternatively, the accessing of the 
resource in. the GSh method can characterize receiving a program module resource &om the 
RDS, loading the program module resource into memory of tbid WAD, executing the 

25 program module resource with the BAD to generate a signal, storing die signal(s) in memory, 
and generating a display with the WAD based on the generated signal. As yet another 
alternative, the accessing of the resource in the fifth method can characterize receiving at the 
WAD via the network a signal 6om the RDS generated based on execution of a server 
^plication by the RDS, storing the received signal in the moiaory of the WAD, genemting 

30 with the WAD a display signal based on the received signal, generating a display with the 
WAD based on the display signal, executing a client application with the WAD to generate a 
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signal based on the signal from the KDS, and transmitting Hie sigQal(s) to fhe RDS via the 
network. The GSh method can further characterize receiving ixtput data at the WAD &om a 
user. The client aiq)lication can be executed based on &e input data. 

A sixth method is characterized by, at a resource distribution subsystem (EUDS)» 
5 receiving a signal requesting access to a resource fix)m a v/eb access device (WAD). The 
signal includes at least a universal resource locator (URLX resource access right data, and 
hash data. The sixth method also is characterized by verifying that the resource access right 
data as set by a resource provider subsystem (RPS) has not been changed, using the hash 
data. The sixth method further is characterized by, if the verifying establishes that the 

10 resource access right data has not been changed, determining whether access to the resource 
is permitted to the WAD and/or user thereof based on the resource access right data. The 
sixth method further is characterized by, if the resource access right data radicates that the 
WAD and^or user thereof is authorized to access the resource, permitting access to the 
resource to the WAD and/or user fliereof The resource access right data can include at least 

15 one of an authorized Memet protocol (BP) address or IP address range, life-span data 
indicating the life-span indicating a time period over which requests for accessing a resource 
are valid, and maximum reference data indicating a maximum nimiber of times a web access 
device and/or user thereof can access a resource. The hash data can be generated based on 
the UKU resource access right data, and key data. The sixdi method can further characterize 

20 receiving key data fcom the EPS for use in verifying that the resource access rig^t data has 
not changed from establisfam^t by the RPS. The key data can include a key and optionally 
at least one of: (1) a second URL identifying the RPS; (2) start date/time data identifying a 
date and time at which a key is valid; (3) end date/tune data identifydng a date and time at 
which a key becomes invalid; (4) life-span data indicating a period of time over which the 

25 key is valid; (5) key index data identifying the key from among a plurality of difGsrent keys; 
(6) hash identifier data indicating to the RDS a hash algorithm to be performed to generate 
the hash data; (7) encryption data indicating an encryption model and/or algorithm used to 
mcrypt and decrypt resource access right dat£^ and (8) format fields data indicating the 
number of fields in the signal requesting access to tiie resource. 

30 A seventh disclosed method is characterized by receiving a signal requesting access 

to a resource. The signal has a secure universal resource locator (URL) with secured 
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resource access right data. The seventh method also is characterized by extracting an 
Internet protocol (IP) address from the secured resource access right data, comparing the 
extracted IP address with the TP address included m a hypertext transport protocol (HTTP) 
message of tibie request signal^ and authenticatmg that the IP address of the secured resource 
5 access right data corresponds to the IP address of a device requesting access to the resource, 
based on the comparing. The seventh method can characterize terminating the request signal 
if the authenticating indicates that the IP address of the secured resource access right data 
does not match the IP address extracted ftom the HTTP message. The seventh method can 
also characterize, if the authenticating indicates that the IP address of the secure resource 

10 access right data matches the IP address of the device requesting access to the resource, 
obtaining a key corresponding to the IP address. The seventh method can also characterize 
verifying whether the key is valid based on data corresponding to the key in a secure content 
key database, generatmg hash data based on at least the IP address, URL, and key, and 
verifying that the generated hash data matches the hash data iacluded in the received request. 

15 signal. The seventh method finther is characterized by terminating the request signal if the 
verifying indicates that the generated hash data does not match the hash data included in the 
received request signaL The seventh method can characterize determining wheflier access to 
a resource is to be provided to a device identified by the IP address, based on the resource 
access right data included in the request signal. The seventh method can also characterize 

20 retrieving the resource based on the URL included within the request signal, and providing 
access to the resource to a device identified by the IP address if the determining indicates that 
access to the resource is to be provided, based on the URL. The seventh method can further 
* chaiaot^izeretrievingre&ourceaccessright data firom a database. The acc^ detennination 
can be performed based fiirfher on whether the IP address of the requ^t signal is authorized 

25 to access the resource indicated by the URL of the request signal, based on the retrieved 
resource access rigjht data. Fur&eimore, the seventh method can characterize terminating the 
request signal if the determining indicates Aat access to the resource is not to be provided 
based on the resource access rig^t data included in the request signal. The retrieved resource 
access rig^ data can include maximum refermce data and reference count data. The seventh 

30 method can further characterize inaementing the reference count data to indicate that access 
to the resource has been requested by ihe request signal, comparing the incremented 
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reference count data with the maximum reference corait data, and providing access to the 
resource if the comparing indicates that the incremented reference coimt data does not 
exceed the maximum reference count data. Furthermore, the retrieved resource access right 
data can include life-span data for access to the resource indicated by the URL. The seventh 

5 method can further characterize determining a time and date of receiving the request signal, 
comparing Ihe life-span data with the time and date of receiving the requesting signal, and 
detemiining that the DP address of the request signal is authorized to access the resource, if 
the comparing indicates that the time and date of receiving the request signal is within the 
• life-span data. The retrieved resource access right data can include URL/resource provider 

10 identification data The seventh method can further characterize retrieving the resource from 
a resource provider subsystem via the Intemet, based on the URL/resource provider 
identification data so that access can be provided thereto. The retrieved.resource access right 
data can include retrieval key data used to decrypt the retrieved resource. 

An eighth method is characterized by receiving a signal requesting access to a 

15 resource. Thb request signal can include a universal resource locator (URL), secured 
resource access right data, and an Intemet protocol (IP) address of a device requesting access 
to the resource, and hash data. The eighth method finther is characterized by voxifying 
whether the key data is valid based on data corresponding to the key data in a secure content 
key database. The eighth mefliod also is characterized by, if the key data is verified as valid, 

20 generating hash data based on at least flie IP address, URL, and key. The eighth method 
further is characterized by verifying that the aerated hash data matches the hash data 
included in the received request signal. The eighth me&od can characterize terminating ttie 
request signal if the verifymg indicates that the generated hash data does not match the hash 
data included in the recdved request signal The eighth method can characterize determining 

25 whether access to a resource is to be provided to a device identified by the IP address, based 
on the resource access ri^t data' included in the request signal, and providing access to the 
resource to a device identified by the JP address if the determining indicates that access to titie 
resource is to be provided. The eigjith method can also characterize retrieving resource 
access ri^t data from a database. The determining can be based fiirther on whether the IP 

30 address of the request signal is authorized to access flie resource indicated by the URL of tiie 
request signal, based on the retrieved resource access right data. Tlie received request signal 
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can characterize key index data used to retrieve the key data from the secure content key 
database. The validity of the key data can be establidied by deterauning a date and time of 
receiving the request signal, retrieving start date/time data and end date/time date from a 
database, comparing the date and time of the request signal with the start date/time data and 

5 end date/time data, and determining whether the key data is valid, based on the comparing. 
Alternatively, the vaUdity of the key data can be established by determining a date and time 
of receiving the request signal, retrieving life-span data from a database, comparing the date 
and time of receiving the request signal with the life-span data, and detemfiining whether the 
key data is valid, based on the comparing. 

10 . A ninth disclosed method is characterized by receivmg via the Internet a request 

signal including a universal resource locator (URL) indicating a location of a r^urce, 
secured resource access right data indicating rights of a device to access the resource, and an 
Internet protocol (IP) address of the device. The nintii method also is characterized by 
detennining whether access to the resource is to be provided to the device identified by the 

15 IP address, based on secured resource access right data included in the request signal. The 
ninth method fiirther is characterized by providing access to the resource to a device 
identified by the IP address if the detennining indicates that access to the resource is to be 
provided. The ninth method can characterize terminating the request signal if the 
detenninmg indicates that access to the device is not authorized. The ninth method can 

20 characterize transmitting the resource to the device via the Litemet Furthermore, the ninth 
method can characterize auflienticating the request signal if an Internet protocol (IP) address 
of the XJRL in the request signal matches a URL of the device contained in the resource 
access ri^t d^ta of the request signal. I^irthecmore, ttie ninth method can characterize 
retrieving resource access rigjit data fi»m a database, and the. access detennination can be 

25 further based on whether the IP address of the request signal is authorized to access the 
resource indicated by tiie URL of the request signal, usmg the retrieved resource access right 
data. Moreover, the ninth method can characterize veri^g validity of key data, ^crating 
hash data based on at least the URL and the key data, comparing the generated hash data 
with hash data included in the received request agnal, and detenmning \rfiefher the 

30 generated hash data matches the hash data generated in the request signal, based on the 
comparing of hash data. Access to the resource can be provided if ttie detemaination 
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wo 02/14«W>l 



PCT/USOl/24398 



establishes that the hash data match. The verifying of tiie data can be perfonned by 
detemdning a date and time of receiving the request signal, retrieving start date/time data and 
end date/time date fiom a database, comparing the date and time of the request signal wifli 
the start date/time data and end date/tune data, and determining whether key data is valid, 
5 based on the comparing. If the key data is determined valid, the determination of wheflier 
access to the resource is permitted can be performed Conversely, if the key data is not valid, 
the request signal can be terminated. The verifying of key data can also be performed by 
determining a date and time of receiving the request signal, retrieving life-span data from a 
database, con[q)aring the date and time of receiving the request signal with the life-span data, 

10 and determining whether key data is valid, based on the comparing. If the key data is 
determined vaUd, the determination of whether access to the resource is permitted can be 
perfonned. Conversely, if the key data is not valid, the request signal can be terminated, 

A disclosed system can be used in connection with the hitemet The system is 
characterized by at least one web access device (WAD) executing a browser application. 

15 The WAD geuCTates a signal requesting a web page document having a secure universal 
resource locator (URL), displays the web page document having the secure URL, and 
generates a signal requesting a resource indicated by the secure URL of the web page 
document The system also is characterized by resource provider subsystem (RPS) coupled 
to receive via the Internet fte signal requesting the web page document fix)m the WAD. The 

20 RPS generates the secure URL to include resource access right data defining F6striction($) of 
the WAD and/or user thereof to access the resource indicated by the URL. The RPS 
transmits the web page document with the secure URL to the WAD. The system further is 
characterized by at least one resource distribution subsystem (RDS) coupled to receive via 
. the Internet the signal fiom the WAD requesting access to ttie resource. The RDS 

25 determines whether ttie resource access ri^t data has been changed fiom establishment by 
the RPS, and, if fho RDS detemiines that the resource access right data has not been 
changed, the RDS detennines whetho: the WAD and/or user th^eof is authorized to access 
the resource using the resource access right data. The RDS permits access to the resource if 
the WAD and/or user thereof is authorized to access the resource. The resource access right 

30 data can include at least one of: (1) an authorized Internet protocol (EP) address or TP address • 
range; (2) life-span data indicating the life-span indicating a time period over which requests 
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for accessing a resource are valid; and/or (3) maximum reference data indicating a maximum 
number of times a web access device and/or user thereof can access a resource. The hash 
data can be generated by the RPS based on the URL, resource access right data, and key data. 
The RDS can store the key data used by the RPS for use in verifying that the resource access 

5 right data has not changed from estabUshment by the RPS. Hie key data can characterize a 
key and optionally at least one of: (1) a second URL identifying the RPS, (2) start date/time 
data identifying a date and time at which a key is valid, (3) end date/time data identifying a 
date and time at which a key becomes mvalid, (4) life-span data indicating a period of time 
over which the key is vali4 (5) key index.data identifying the key from among a plurality of 

10 different keys, (6) hash identifier data indicating to the RDS a hash algoritei to be 
p^formed to generate the hash data, (7) encryption data indicating an encryption model 
and/or algorithm used to enciypt and decrypt resource access right data; and/or (8) format 
fields data indicating the number of fields in the signal requiting access to the resource. 

A first disclosed server stores a secure universal resource locator (URL) generator 

15 module executable by the server to generate a URL having secure resource access right data 
defining restriction(s) on a web access device (WAD) and/or user thereof to access a 
resource indicated by the secure URL. The resource access right data is secured by the server 
so that modification of the resource access right data can be detected. The server can store a 
secure content key database having key data, and the server can execute the secure URL 

20 generator module to secure the resource access right data with the key data. The server can 
dpp^nd die key data to an Internet protocol (BP) address of the WAD requesting the web page 
document from the server, and can hash the key data and the IP address to generate hash 
data. The hash data can be combined with flie URL and resource access right data to 
generate the secure URL. The server can use the key data to enoypt the resource access 

25 right data and can combine the CTCTypted resource access right data with the URL to produce 
tibie secure URL. The server can characterize a resource access rigjit database storing the 
resource access right data. The server can characterize an access right enforcer module, that 
the server can execute to determine whether a resource is to be provided to another server in 
response to a request signal received from the other server via the Ihtemet. The server can 

30 execute a secure caching module to transmit the resource to flie other servw for distribution 
if the resource access right data mdicates that die other server is authorized to access the 
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resource. Conversely, the server can prevent access to the other server if the resource access 
right data indicates that the other server is not authorized to access the resource. 

A second disclosed serv©: of a resource distribution subsj^em ORDS) stores an 
access right enforcer module executable by the server. The server executes the access right 

5 enforcer module in response to a signal from a web access device (WAD) requesting access 
to a resource. The request signal has a universal resource locator (URL) with secure r^urce 
access right data. The server executes the access right enforcer module using resource access 
right data to determine whether the resource access right data has been modified after its 
establishment by a resource provider subsystem (RPS). If the resource access right data has 

10 not been changed, the server executes a secure caching module to provide access to the 
resource, provided that the WAD is determined to have the right to access the resource as 
detemrined by the resource access right data. The server blocks access to the resource if the 
resource access rigjit data has been changed or if the WAD is deteimined not to have the 
right to access the resource jfrom the resource access ri^t data- The request signal received 

15 by the server from the WAD can include an totemet protocol (IP) address, a universal 
resource locator (URL) indicating the location of the resource, and hash data. The server can 
retrieve key data based on the IP address and/or URL. The server can combine the key data 
with at least the IP address and/or URL. The server can generate hash data based on the key 
data and JP address and/or URL. The server can compare the s^er-gcaaerated hash data 

20 with flie hash data in the request sigoal. If flie hash data matches, the server can execute its 
secure caching module to provide access to flie resource. Conversely, if the hash data do not 
match, the server can block access to the resource. The server can retrieve date/time data 
from a secure content key database stored therein. The date/time data can indicate a period 
of time over which the key data is valid. The server can record the date and time of receiving 

25 the request signal at the server and can compare the date and tune of receipt of the request 
signal with the date/lime data to detemiine whether the key data is valid The server can 
pennit further processing of the request signal if the comparison indicates the key data is 
valid, and can terminate further processing of the request signal if the date/time data 
indicates the key data is not valid. The servo: can fiirflier retrieve from the secure contrat 

30 key database life span data that the SOT^er uses hi conjunction with the date/^time data to 
deteraune the period of time over which the key is valid so that date and time of recdving 
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the request signal at the server can be compared by the server with the date/tfane data and 
life-span data to detennine whether the key is vaKd. 

Details of the construction and operation of the invention are more fiilly hereinafter 
described and claimed In the detailed description, reference is made to the accompanying 
5 drawings, forming a part of this disclosure, in which like numerals refer to like parts 
tooughout the several views. 

BiUEF Description OF THE Drawings 
Figs. 1 A-1 G are views of a method of the invention illustrating how a resource can be 
distributed wititrin a system of the invention; 
10 Figs. 2A-2E are views of a method of the invention indicating a resource can be 

accessed at a distribution server in the system; 

Fig. 3 is a block diagram of a web access device (WAD) of the invention; 
Fig. 4A is a flow chart of a method performed by a WAD to obtain access to a 
resource, and Figs. 4B - 4D are flowcharts of methods indicating how access to the resource 
15 is provided to a WAD depending upon the nature of the resource; 

Fig. 5 is ablock diagram of a resource provider subsystem ("RPS") of the invention; 
Fig- 6 is a flowchart of processmg performed by a web server of the RPS; 
Fig. 7 is a block diagram of a resource distribution subsystem C'RDS") of the 
invention; 

20 Fig. 8 is a flowchart of processing performed by the resource distribution server of 

the invention; 

Figs. 9A " 9B show a secure content key database for storing hash keys and data for 
use in validating hash keys; 

Fig. 9C is a database for storing resource access right data; 
25 Figs. lOA - IOC indicate different formats for the unsecure and secure URL having 

resource access right data; 

Fig. 1 1 A is a block diagram of a method for gena:ating a secure URL having resource 
access ri^t dat^ 

Fig. IIB is a block diagram of a method of generating a web page document having a 
30 secure URL with resource access ri^t data; * 

Fig* 12 is a block diagram of a method for decoding resource access right data; 
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Fig. 13A is a flowchart of a method of authenticatmg an ff address of a WAD at a 
server of a RDS; 

Fig. 13B is a flowchart of processing perfonned to check the field format of a secure 
URL with resource access right data received at a server of a RDS; 
5 Fig. 13C is a flowchart of hash key vaKdation perfonned by a server of a RDS; 

Fig. 1 3D is a flowchart of hash verification performed by a server of a RDS; 
Fig. 13E is a flowchart of resource access right verification performed by a server of 

a RDS; 

Fig. 13F is a flowchart of resource access verification performed by server of a RDS; 
10 Fig. 13G is a flowchart of resource access verification perfonned by a server of a 

RDS; 

Fig. 13H is a flowchart of resource access verification perfonned by a server of a 

RDS; 

Fig. 131 is a flowchart of resource access verification perfonned by a server of a 

15 RDS; 

Fig. 14 is a block diagram of a resource handler for providing resource data to a 

WAD; 

Fig. 15 is a resource handler for loading and launching an plication resource in 
response to a request fiom a WAD; and 
20 Fig. 16 is a schematic diagram of a resource distribution networic system in 

accordance with the invention. 

Mo]>E(s) FOR Carrying Out the Invention 
1, Definitions 

"And/or** means either or botL 

25 "Authentication" refers to verification that a resource provider has authorized access 

to a resource to a particular web access device, an Internet Protocol (IP) address thereo:^ or a 
user. Authentication can be perfonned by comparing an Internet protocol (EP) address in a 
hypertext transport protocol OEmP) request signal with the IP address m a secure URL 
portion of the request sigqal. Alternatively, or in addition, authentication may be perfonned 

30 by successfiil decoding of resource access rig^t data, or by performing a hash algorithm on 
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resource access right data and comparing the hash with that received with a request for 

access to the resource from a web access device. 

"Communication interfece unit" can include a modulator/demodulator Cmodem^'X a . 

waveguide, optical or wireless transceiver, EthOTiet® card, or other device fliat permits a 
5 SCTver or device to access a network, 

"Coupled" refers to joining a web access device(s), server(s), or database storage 

unit(s) so as to pennit signals to propagate therebetween. Such signals can be in electronic 

form and transmitted between coupled elements by a conductive line such as a wire or cable 

or other waveguide, or via wireless transmission of signals through air or other media, for 
10 example. Alternatively, such signals can be in optical form and transmitted via optical fiber 

or other waveguide, or by transmission of signals through air, space or other media, for 

exan:Q)le. 

"Client" is a program or device that is capable of accessing shared network resources 
provided by a server. 

15 "Data storage unit" refers to a memory storage with random-access memory, hard- 

disk drive, tape or other storage medium type for the storage of data. The data storage unit 
can be controlled with commercially-available software packages such as Oracle 9i from 
Oracle® Corporation, Redwood City, California. The web server can comnaunicate with the 
data storage unit through an application program inter&ce (API) such as Java DataBase 

20 Connectivity (JDBC) or Open DataBase Connectivity (ODBC). 

'T>isplay unit" can be a flat-panel liquid crystal display (LCD) or a cathode ray tube 
(CRT), for example. 

"Document", "web page" or "web page document" refers to a docummt in hypertext 
maik-up language (ETIML), ©rtensible mark-up language CXML), or oiha: language that 
25 includes a computer-readable code that can be used to generate a display with a web browser. 

"Encode" refers to preparing a URL string in a manner that can be interpreted by an 
operating sj^em and/or ^plication hosted on a server, 

"File" refers to a set or collection of data. 

"Graphical user mterfece" or "GUI" refers to the display and input unit of a web 
30 access device that a user operates to interact with the web access device. 
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••Input device" refers to a keyboard, mouse, wand or any other device that can be 
operated by a user to input commands or data into a web access device. 

"Key" or "k^ data" refers to a series of bits used for hashing or encrypting/decrypting 

data. 

5 "Log in" and "log out" refer to beginning and ending stq)S of a session of interaction 

between a web access device and a server. Generally, "log in" entails entering user name and 
password at a web access device and submitting these to a server. The server and/or 
database storage unit can be used to store user data associated with the user name and 
password. 

10 "Memory" or "Processor-readable memory* includes a random-access memory 

(RAM), read-only memory (ROM), programmable read-only memory (PROM), electrically- 
erasable read-only memory (EEPROM), compact disc (CD), digital versatile disc (DVD), a 
magnetic storage medium such as a floppy disk or cassette, hard disk drive, and/or other 
storage device. Such memory can have a byte storage edacity from one Megabyte to several 

15 Gigabytes or more, for example, 

•"Module" refers to conoputer code executable by a processor of a computer or server. 
"Network" can be local area network (LAN), wide area network (WAN), 
metropolitan area network (MAN)> "tiie Internet", a virtual private network (VPN) or other 
network, for example. The "network" establishes communication between q)plications 

20 running on web access device and server(s). Such communication can be in accordance with 
the ISO/OSI model, for exaiiq>le. 

"Operator" refers to a programmer or systems administrator of either the resource 
provider subsystem ("RPS") or flie resource distribution subsystem ("RDS"). 

"Operating system" is a coniputer program that enables a processor within a web 

25 server or wd> access device to communicate with ofhet elements of such systems. Such 
operating systems can include Microsoft® Windows 2000™,^ Windows NT™ , Windows 
95™, Windows 98™ , or disc-operating system (DOS), for example. Such operating 
systems can also include the Java-based Solaris® operating system by Sun Microsystems, the 
UNK® operating system, LMJX® operating system, and others. 

30 "Processor" can be a microprocessor such as a Pentium® series noicroprocessor 

commercially-available from fiitel® Corporation, a microcontroller, programmable logic 
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array (PLA), field programmable gate array (FPGA), programmable logic device (PLD), 
programmed array logic (PAL), or oth^ device. 

"Proc^sor-readable medixan" includes aa electronic, magnetic, magnetoelectronic^ 
micromechanical, or optical data storage media. The computer-readable mediimi can include 
5 compact-disk read-only memoiy (CD-ROM), digital VCTsatile disk (DVD), magnetic media 
such as a floppy-disk or hard-disk, hard-disk storage units, tape or other data storage 
medium. 

"Resource access right data" is data that can be used to limit or control access to a 
resource. 

10 '^Resource" can be data, te?ct, an image me(s), sound file(s), video file(s), one or more 

web page documents and/or an ^plication or computer program, or data, text, and image 
file(s), sound file(s), video file(s) resulting from execution of a computer program. 

"Server" is a computer or program operating on the Ihtemet or other network 
environment, that responds to commands from a client. 

15 "(s)" at the end of a word means "one or more." For example, "part(s)" means "one or 

more parts." 

"Transxmssion media" includes an optical fiber, wire, cable, or other media for 
transmitthxg data in optical or electric form. 

"Universal Resource Locator** or "URL" is the address of a device such as a client or 
20 server accessible via Memetwork. 

"User** generally refers to a human operator of a web access device. 

"Web access device" is a device that accesses resources of another device (e.g., 
server) via a network. The web access device can be a personal computer, a network 
terminal, a peisonal digital assistant, or other coniputing or processor-based device, 
25 "Web browser" or "browser" is an plication program that has the capability to 

execute and display an HTML and/or extensible maxk-i^ language (XML) document, for 
example, and that interacts with one or more s^ers via a network. For example, the web 
browser can be Internet Explorer® version 5 program available fiom Microsoft® 
Corporation, Redmond, Washington, or Communicator® vision 4.5 program available fix)m 
30 Netscape, Inc. "Web browser" also encompasses within its meaning HTML and/or XML 
viewers such as those used for personal digital assistants (PDAs). 
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"Web server" generally refers to a computing device available commercially from 
numerous sources such as Alpha Microsystems®, Santa Ana, California, Intel® Corporation, 
Hewlett-Packard® Corporation, Sun Microsystems®, Inc. capable of serving data or files to 
client ^plications via hypertext-tranqjort protocol (HTTP) and executing server-based 
5 applications such as CGI scripts, or Java® servlets, or Active server pages, for example. 

2, General System AND Method 
Figs. lA - IG and 2A - 2E are views of a general system 10 that is characterized by 
web access device 12, resource provider subsystem ("RPS") 14, resource distribution 
subsystem ("RDS") 16, coupled via network 18, The web access device 12 can be a 
10 processor-based device capable of executing a browser application. The web access device 
12 can include a display unit 20 and an input device 22. In Fig. lA, the web server 30 of the 
RDS 16 is provisioned with key data stored in the RPS 24. The key data permits the 
subsystem 16 to authenticate and verify requests to access a resource from a user and/or web 
access device. In Fig. IB, the web access device (WAD) 12 generates a signal requesting a 
15 web page document from the RPS 14. The WAD 22 can be programmed to generate this 
request signal automatically, or a user of the WAD 22 can operate the input device 22 to 
gmerate such signal. The WAD 12 transmits the request signal to the RPS 14 via the 
network 18. 

The RPS 14 can include a web server 24 and a data storage unit 26. The web server 
20 24 is coupled to receive the request signal from the WAD 12 via the network 18, and 
retrieves the requested web page document from the data storage unit 26, as shown in Fig. 
IC. Alternatively, in response to the request signal, the web server 24 can retrieve data from 
the data storage unit 26 for use in assembling a web page document "ooa-the-fly" for 
transmission to the WAD 12. The web server 24 finds any universal resource locator(s) 
25 (URL) referenced in an eadsting w^eb page document or to be included within a web page 
document assembled on-the-fly by the web s^er 24. The web server 24 is programmed to 
associate resource access right data with the URL. The resource access ri^t data defines the 
WAD*s and/or user's ri^bts to access the resource. The web server 24 can also associate a 
file path indicatmg the data storage location of the resource at the RPS 14 and/or the RDS 16 
30 in the secure URL. 
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The web server 24 can retrieve ttie resource access right data based m one or more 
factors. The web server 24 can include a data table storing resource access right data in 
correspondence with die identity of the user of the WAD. The user's identity can be 
determined by web server 24 from a log-in procedure to commence a sesaon between the 
5 WAD 20 and the web server 24. Alternatively, the user's identity can be detennined by the 
web server 24 if a cookie has been previously loaded into the WAD 12 to identify tiie WAD 
and/or user thereof to the web server 24. Alternatively, or in addition, the web server 24 can 
store the resource access right data m correspondence with an IP address of the WAD 12, 
The IP address of the WAD 12 is inherently supplied to the web server 24 in the request 

10 signal in the IP protocol in version 3,0 and later versions of this protocol estabUshed by the 
Institute of Electrical and Electronics Engineering (IEEE). The web server 24 can thus 
retrieve the resource access right data based on the identity of tihie WAD 12 and^or the xiser 
thereof The web server 24 also retrieves from a data table stored therem hash and/or 
encryption key data for hashed and/or encrypted data included as part of the resource access 

15 right data. The hash and/or encryption key data can be stored in the web server 24 in 
correspondence vwth the URL or identity of the server hosting the resource. The web server 
24 retrieves the hash and/or encryption key and uses it to hash and/or enaypt die retrieved 
resource access right data. As shown in Fig. IB, the web server 24 combines the resource 
access ri^t data with the URL and encodes the resulting secure UKL data string into a form 

20 that can be executed by web server 30* Depending vpon how the web server 30 is 
progiOTuned, such web server can either rqplace an existing URL with the secure URL or 
may combine the secure URL with other elements of the web page document "on the fly" as 
such web server generates the web page document The web server 24 transmits the web 
page document having the secure URL with the secure resomce access rigiht data to the 

25 WAD 12 via the network 18. The WAD 12 receives and executes die web page document 
The execution of script m the web page document by the WAD 12 can result in generation of 
a display 28 that includes the secure URL. 

As shown in Fig, ID, the WAD 20 can. generate a signal including a URL with access 
right data to request access to a resource designated by the URL. The signal can be 

30 generated by the WAD 12 automatically as it executes script in the web page document 
Alternatively, the WAD 12 can generate the signal including die URL with secure resource 
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access right data in response to operation of the input device 22 by the user of the WAD 12, 
such as by "cKcking" or activating a hyperlink for the XJRL using the input device 22. The 
signal requesting access to the resource designated by the URL, including the URL with 
secure resource access right data, is transmitted by the WAD 12 to the RDS 16 via the 
5 network 1 8 using the URL to address the web s^er 30, 

The RDS 16 can include a web server 30 and a data storage unit 32. The web s^er 
30 is coupled to receive the signal requestiag access to the resource that includes the URL, 
data fields indicating a file path to the data storage location of the resource, and the resource 
access right data that defines the rights of the WAD and/or user to access the resource in a 

10 secure manner which prohibits tampering with such data. The web server 30 stores key data 
used to verify that the WAD 12 is peraiitted to access a resource based on the resource 
access right data. This key data can be a shared key or public/private key pair, for example. 
The web server 30 uses the key data to decrypt or match hash data within the resource access 
right data or derived tiierefit>m to verify that the WAD and/or user is authorized to access a 

15 resource. The resource access right data serves to limit or restrict the ability of a WAD 
and/or use to access the resource. The web server 30 determines the resource access right(s) 
of the WAD 12 and/or the user of the WAD, based on the decoded resource access right data. 
If the web server 30 determines that ttie decoded resource access right data does not 
authorize the WAD 12 and/or the user of the WAD to access the resource, the web server 30 

20 can generate and transmit a signal indicating denial of access to the WAD via the netwoik 
18. The WAD 12 can generate a display indicating denial of access to the resource based on 
die denial-of-access signal fiom the web server 30. Conversely, if the web server 30 
determines that access to the resource is permitted based on the decoded resource access 
right data, the web server 30 determines whether the data storage unit 32 includes the 

25 requested resource. If the resource is not present in the data storage unit 32, the web server 
30 generates a signal to request the resource firom the resource provider subsystem 14. In 
this case, the web server 30 transmits the request-for-resource signal to the web s^er 24 of 
fixe resource provider subsystem 14, as shown in Fig. IE. 

The web server 24 is coupled to receive Oxo request-for-resource signal fiom the RDS 

30 16 via the netwoik 18. The web server 24 retrieves the resource fiom the data storage unit 
26 using the URL and file path in the signal received by the RDS 1 6 from the WAD's signal. 
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The web server 24 encodes and transmits the resource data to flie web server 30 of the RDS 
1 6. The web server 24 can encrypt the resource data using key data so timt the resource data 
is secure in transmission to the RDS 16. The web server 24 generates and transmits a signal 
including the resource data to the web server 30 of the RDS 16 via liie network 18, as shown 
5 in Fig. IF. 

Still referring to Fig, IF, the web server 30 of the RDS 16 is coupled to receive the 
■ signal including the resource data from the resource provider subsystem 14 via the network 
18» The web server 30 executes its operating system and/or an application program to 
decode the resource data. The web server 30 can decrypt the resource access rigjit data using 
.10 key data corresponding to the requested URL. The web servo* 30 stores the resource data in 
the data storage unit 32. If the resource data is in the form of text, or one or more images, or 
one or more applets, in a web page document, for example, the web server 30 can transmit 
the resource data to the WAD 12 via the network 18, as shown in Fig. IG. Optionally, the 
web server 30 can encrypt the resource data before transmission to the WAD 12. The WAD 

15 12 can be coupled to receive the resource data signal from the network 1 8. The WAD 12 can 
execute soipt in the web page document to generate a display with display unit 20, based on 
the resource data^ Conversely, if the resource is a server application, the web server 30 can 
load and execute the server application(s) to generate signals exchanged with the WAD 12 
via the network 18 to permit the user of the WAD to use the server ^plication resource. 

20 Figs. 2A - 2E are views of a method for accessing a resource via the WAD 12 in 

which the resource has been stored on the data storage unit 32 of the RDS 16 before 
execution of the method. The resource may have been stored in the data storage unit 32 as a 
result of previous performance of the method of Figs. 1 A - IG, or alternatively, may have 
been physically sent by maU or transmission over the network 18 along with the key data and 

25 stored in flie web server 30 and data storage unit 32 to prepare the RDS 16 for performance 
of the method of Figs. 2A - 2E. 

In Fig. 2A, the RDS 16 is provisioned with key data stored in the RPS 14. The key 
data permits the web serv^ 24 to secure resource access right data so that it cannot be 
changed or tampered with by a user of the WAD 12. The resource access rigjat data can thus 

30 be controlled by the RPS 14 even though RDS 16 is used to remotely distribute the resource. 
The key data further permits the web server 30 to authenticate and verify the WAD's and/or 
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us^s request to access the resource as well as to detennine the rigjits of such WAD and/or 
user has to use the resource. In Fig. 2B, the WAD 12 generates a signal requesting a web 
page document torn the HPS 14. The WAD 12 transmits the signal requesting the web page 
document to ttie RPS 14 via the network 18. The RPS 14, or more specifically, the web 
5 server 24, is coupled to receive the request for the web page document ftom the WAD 12. 
The web server 24 of the RPS 14 retrieves the web page document(s) from the data storage 
unit 26. The web server 24 finds URL(s) within die web page document, and retrieves 
resource access right data for the URL(s). The web server 24 can retrieve the resource access 
right data based on the URL(s), as well as the identity of the user and/or the identity of the 

10 WAD 12, for example. The web server 24 encodes the resource access right data using key 
data stored in such web server, and combines the resource access ri^t data wifh the secure 
URL(s) in the web p^e document Alternatively, the RPS 14 can retrieve data including one 
or more URLs from the data storage unit 26 using tiie WAD*s IP address and/or identity of 
■ the user of the WAD. The RPS 14 can retrieve secure resource access right data for the IP . 

15 address and/or user identity from its data storage unit 26, The RPS 14 can perform a hash of 
all or a portion of the resource access right data, and can combine tiie secure URL(s) with 
data for the web page retrieved from the data storage unit 26. The RPS 14 can combine the 
secure resource access rigjit data with respective IJRL(s) to generate secure URL(s). The 
web server 24 can fiirther retrieve data from the data storage unit 26, and can assemble such 

20 data with the secure URLs to generate a web page docummt wifii secure URLs designatmg 
the IP address and file pa£h of a resource and the requesting WAD's or user's rights with 
respect thereto. The web server 24 transmits the web page document including the URL(s) 
with secure resource access right.data to the WAD 12. He WAD 12 is coupled to receive 
the web page document having the secure URL(s) with the resource access right data. The 

25 WAD 12 can generate a display 28 on the unit 20 based on the web page document having 
the URL(s) with secure resource access right data, as shown in Fig. 2C. 

In Fig. 2D the WAD 12 generates a signal requesting access to a resource indicated 
by the URL(s) with resource access right data. This signal can be generated automatically 
by the WAD 12 in the execution of script included ia the web page, or by the operation of 

30 the mput device 22 to cause the WAD 12 to generate the signaL The WAD 12 transmits the 
signal requesting access to ttie resource vnfk the URL(s) with respective secure resource 
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access right data, to the web server 30 of the RDS 16. The web server 30 is coupled to 
receive the signal requesting access to the resource fixan the WAD 12 via the network 18. 
The web server 30 decodes the secure URL, and retrieves key data for the secure URL and/or 
IP address of the WAD from its memory. The web server 30 can check flie secure URL for 

5 proper formatting of data fields. The web server 30 uses the key data to authenticate the IP 
address of the WAD 12. In addition, the web server 30 verifies the integrity of the secure 
resource access right data by either decrypting such data or performing a hash operation and 
matching the resulting hash to one inserted in the secure URL string by the RPS 14. The 
web server 30 determines whether the WAD 12 and/or user of the WAD is authorized to 

10 access the resource, based on the secure resource access right data received fipom the WAD 
12. If the web server 30 determines that the user and/or WAD 12 is not authorized to access 
the resource, the web server 30 can generate and transmit a denial of access signal to the 
WAD 12 via the network 18. The denial-of-access signal can be used to generate a display 
28 on the unit 20 to indicate that the user and/or WAD 12 is not authorized to access the 

15 resource. Conversely, if the web server 30 determines fliat the user of the WAD 12 and/or 
the WAD is authorized to access the resource, the web server 30 retrieves the resource fix>m 
the data storage unit 32. The web server 30 can use a field path to determme flie data storage 
location of the resource. If the resource is data such as text, image(s), or applet(s), the web 
server 30 generates a signal including the resource data and transmits such resource data to 

20 the WAD 12 via the network 18, as shown in Fig. 2E. If the resource is a server ^plication, 
the web server 30 loads and executes the server application. The web server 30 can execute 
the loaded server application to generate a signal(s) exchanged with signal(s) of the WAD 12 
to permit the user of the WAD to intwact with the web server 30 over the network 18, as 
shown in Fig. 2E. 

25 3. Web ACCESS Device ANp Related METHODS 

Fig, 3 is a view of an exemplary embodiment of the WAD 12. The WAD 12 can 
include a display unit 20, and input device 22, a processor . 34, a memory 36, and 
communication interface unit 38, coupled to the bus 40. The communication interface unit 
38 is additionally coxq)led to communicate with the netwoik 18 through optical or electronic 

30 transmission media, or through transmission/reception of wireless signals. 
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Fig. 4A is a flowchart of processing perfomed by the processor 34 of the WAD 12, 
la step SI the method of Fig. 4A begins. Li step S2 the WAD 12 generates and tcansniits a 
signal requesting a web page document ftom the RPS 14, More specifically, the WAD 12 
executes a browser application program stored in the memory 36. Based on execution of the 
5 browser application program, the processor 34 generates a display signal supplied to the unit 
20 via the bus 40. The display unit 20 generates a display 28 based on the execution of the 
browser application. The browser application may be such as to cause the processor 34 to 
automatically generate a hypertext transfer protocol (HTTP) signal to request access to tiie 
URL designating the RPS 14. Altematively, the user of the WAD 12 can operate the ixxpat 

10 device 22 to input the URL of the RPS 14 and to cause the processor 34 to gen«:ate the 
HTTP message to the RPS via the network 18. The communication interface unit 38 is 
coupled to the processor 34 to receive the HTTP signal requesting a web page document 
hosted by the RPS 14, as indicated by the URL included in Ae HTTP message. The 
communication interface unit 38 transmits the HTTP message to the web server 24 via the 

15 network 18. Optionally, the processor 34 can encrypt the HTTP message using key data 
previously programmed into the memory 36, or previously estabUshed througji a log-in 
procedure to initiate a session with the RPS 14. The HTTP message requesting the web page 
document from the RPS 14 can be transmitted in transfer control protocol/bitemet protocol 
(TCP/IP) over the network 1 8. 

20 hi step S3 of Fig. 4A, the WAD 12 receives a signal mcluding the requested web 

page document. More specifically, the WAD 12 receives a web page or hypertext mark-up 
language (HTML) document including flie URL with the resource access right data. The 
WAD 12 receives the web page documeat as a signal , from the network 18 at tiie 
communication interfece unit 38. Tlie processor 34 coordinates transfer of the web page 

25 document from the communication interfece unit 38 to the memory 36 via the bus 40. The 
processor 34 executes the browser q^plication and the web page document to generate a 
display signal supplied to the display unit 20. The display unit 20 generates the display 28 of 
the browser and web page document based on the display signal from the processor 34. 

hi step 84 of Fig. 4A the WAD 12 executes the browser ^plication and web page 

30 document^ optionally in response to activation of the input device 22, to generate the signal 
to request access to the resource identified by the URL with r^ource access right data 
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included in the web page document. The processor 34 of the WAD 12 can execute the 
browser application and script in the web page document to generate the signal to request 
access to the resource identified by the URL with the resource access right data. The 
processor 34 can generate the signal requesting access to the resource as an HTTP message. 
5 The processor 34 of the WAD 12 supplies the HTTP message having the URL with the 
secure resource access right data to the communication mter&ce unit 38 that transmits the 
HTTP message to the RDS 16 via the network 18. 

In step S6 of Fig. 4A the RPS 16 determines whether access to the resource is 
permitted to the user and/or WAD 12. If not, the RPS 16 generates and transmits a signal 

10 indicating dem'al of access to the resource to the WAD 12 via the network 18. In step S7 the 
WAD 12 receives the signal indicating denial of access to the resource. In step S8 the WAD 
12 generates a display 28 indicating denial of access to the user of the WAD. 

Conversely, if in step S6 of Fig. 4A the RDS 16 determines that access to the 
resource is permitted, the WAD 12. can access the reso\irce in step S9. After performance of 

15 steps 88 or S9, processing performed by the processor 34 by executing its brows©- 
^jplication and/or web page document ends in step S 10. 

The flowcharts of Figs. 4B, 4C, and 4D correspond to step S8 of Fig. 4A, namely, 
providing access to the resource, for different types of resources that can be hosted by the 
KDS. The flowchart of Fig, 4B relates to processmg performed by the processor 34 of the 

20 WAD 12 in the case in which the resource is data such as text, image(s) in a web page 
document, for example. In step 8902 of Fig. 4B the WAD 12, or more specifically, the 
processor 34, receives the resource data from the KDS 14 via the network 1 8. The processor 
34 can receive the resource data from the network via the cormnunicatian inter&ce unit 38. 
More specifically, the communication interface unit 38 receives &e resource data firom the 

25 wd> server 30 of the RDS 14, and supplies the resource data to the processor 34 via the bus 
40. In step S904 of Fig. 4B the processor 34 stores the resource data in the memory 36 via 
the bus 40. In step S906 ttie processor 34 executes the ^plication program stored in tihe 
memory 36 based on the resource data to generate a siigniai(s). In Step S908 the processor 34 
generates the display 28 on the WAD 12 based on the sigQal(s) generated in st^ S906. After 

30 performance of stq) S908 processing proceeds to and tenninates in step SIO of Fig. 4A. 
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The flowchart of Fig. 4C indicates processing performed by the processor 34 in a 
case in which the resource is a downloadable program module. After an aflSrmative 
determination in step S6 of Fig. 4A, tiie processor 34 receives the program module resource 
from the web server 30 of the RDS 16, More specifically, the communication interface unit 
5 38 receives the program module from the web server 30 via the network 18. The 
commxmication interface unit 38 transmits the program module to the processor 34 via the 
bus 40. In Step S904 the processor 34 loads the program module resource into the memory 
36. The WAD 12 executes the program module with the processor 34 of the WAD 12. In 
step S906 the processor 34 executes the program module to generate a signal(s). In step 

10 S908 the signal(s) can be stored in the memory 36 of the WAD 12. In step S910 the 
processor 34 generates the display 28 on the unit 20 based on the signal(s). After 
performance of processing of Fig. 4C, processing performed by the processor 34 proceeds to 
and terminates in step S 1 0. 

Fig. 4D is a flowchart of processing performed by the processor 34 in a case in which 

15 the resource is a client ^>p]ication. After detenrdning that the WAD 12 is authorized to 
access the server application in step S6 of Fig. 4A, the processor 34 receives signal(s) 
generated by the web server 30 of the RDS 16 by execution of the server application in step 
S902 of Fig. 4D. More specifically, the communication inter&ce unit 38 receives the 
signal(s) from the web server 30 via the netwoA 18, and transmits the received signal(s) to 

20 the processor 34 via the bus 40. hi step S904 of Fig. 4D the processor 34 stores ttie decoded 
signal(s) in the memory 38 via the bus 40. .In st^ S906 the processor 34 generates a display 
signal based on the signal(s) from the wd> server 30. hi step S908 tihe processor 34 generates 
the display 28 based on the display signal. In step S91 0 the processor 34 determines whether 
input data has been generated by the user via the ioput device 22. If so, in step S912, the 

25 processor 34 receives input data generated by the user via the input device 22. After a 
negative determination in step S910 or performance of step 912, the processor 34 executes 
the application program stored in the memory 36 to generate a signal(s) based on the 
8ignal(s) received 6om the web server 30 and optionally also the input data generated by the 
user. In step S916 of Fig. 4D the processor 34 transmits the signal(s) generated in step S908 

30 to the RDS 16 via the network 18. In step S918 the processor 34 determines whether another 
signal(s) has been received from the web server 30. If so, processing performed by the 
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processor 34 returns to step S902. Conversely, if the determination in step S918 is negative, 
processing performed by the processor 34 proceeds to and terminates in step SIO of Fig. 4A. 
4. Resource Provider Subsystem f ^'RPS") and Rela ted Methods 
The RPS 14 is shown in relative detail in Fig. 5. The RPS 14 includes the web server 
5 24 and the data storage unit 26. The web server 24 includes a processor 42, a memory 44, a 
communication interface unit 46, input device 48, and output device 50, coupled to bus 52. 
The communication interface unit 46 is coupled to tiie network 18 through wire, optical 
fiber, or wireless transmission media. The processor 42 is coupled to the data storage unit 26 
via the bus 52. 

10 The memory 44 can store an operating system that pennits the processor 42 to 

communicate with the memory 44, communication interface unit 46, the input device 48, the 
output device 50, and the data storage unit 26, via flie bus 52. The memory 44 stores various 
program modules containing computer code executed by the processor 42 to perform various 
fimctions in coordination with flie operating system. More spedficaUy, tiie memory 44 

15 stores a secure URL gmerator module, an access right enforcer module, a secure caching 
module, a communication module, and optionally a user authentication module. The 
memory 44 also stores a secure resource key database that includes key data and resource 
access right data. Furthermore, the memory 44 can store user authentication data including 
usemame/password data in which case the user authentication module performs the functions 

20 of the session layer in Ihe BO/OSI model IEEE specifications. The secure URL generator 
module is executed in response to a request signal from the WAD 12 requesting a web page 
document The request signal can be initially handled by the communication module that 
manages reception and transmission of signals over the networic 18 in coordination with the 
operating system. The secure URL generator module is executed by the processor 42 to 

25 retrieve the requested web page document, and to find any URL(s) within the web page 
document. The secure URL generator module retrieves key data and resource access ri^t 
data for the URL(s) firom the secure resource key database. The secure URL geuOTtor 
inodule secures the resource access right data using the key data. If more than one key is 
used in the system 10, the secure URL generator module can also append key mdex data 

30 indicating the key to be used by the RDS 16 to verify a request to access the resource fix>m 
the WAD 12. The secure URL generator module combines the resource access right data 
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with its corresponding URL in the web page documeat The secure URL generator module 
calls the commimication module that handles transmisaon of the web page document having 
lJRL(s) with resource access right data, to the WAD 12. The access ri^t aiforcer module 
is launched by processor 42 upon receiving a resource request signal firom the RDS 16. TTie 
5 access right enforcer module determines whether the RDS 16 is authorized to receive the 
requested resource. If so, the access right enforcer module calls the secure caching module 
that retrieves the resource &om the data storage unit 26 and retrieves key data corresponding 
to the RDS requesting the resource. The secure caching module encodes the resource with 
the key data, and calls the conmiunication module to transmit the encrypted resource to the 

10 requesting RDS. The communication module generates a signal including the encrypted 
resource and transmits such encrypted resource to the communication interface unit 46 for 
transmission to the RDS 16. The input device 48 and output device 50 can provide a 
graphical user interface (GUI) in connection with a server program (not shown) that permits 
an operator of the web server 44 to perform administrative tasks such as loading or updating 

IS the operating system and various program modules, web page document(s), data» and 
re8ourc6(s) stored in the m^ory 44 and the data storage unit 26. 

Fig. 6 is a flowchart of processing performed by the RPS 14. In step SI the method 
of Fig. 6 begms. In step S2 the processor 42 of the RPS 14 receives an HTTP request for a 
web page document torn a WAD 12 via the network 18. The processor 42 executes the 

20 communication module stored in the memory 44 to perform the message handling necessary 
to receive tihe request from the WAD 12 via tiie network 18. In step S3 the processor 42 of 
the RPS 14 executes the secure URL generator module to retrieve from its memory 44 data 
for the requested web page document including URL(s) and data path(s) of the respective 
resource(s) referenced m &6 web page document In step S4 the processor 42 executes the 

25 secure URL generator module to retrieve resource access right data for URL(s) using an IP 
address of a WAD 12 and/or user name and password established by a log-in procedure 
through execution of the session layer in the ISO/OSI model. In step SS fiie processor 42 
executes the secure URL generator module to retrieve key data from its memory 44. The 
processor 42 executes such module to generate hash or ena^pted data from a portion of the 

30 URL, which g^ierally includes the ff address of the WAD 12 and possibly oth«r data as 
well. The processor 42 fiirfher executes the secure URL generator modide to combine with 
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resource access right data. In step S6, through execution of the secure URL generator 
module^ the processor 42 combines tiiie secure resource access rigiht data with the URL(s) to 
produce a secure URL(s), and encodes the resulting secure URL into a form readable by the 
WAD 12 or server 30 of RDS 16. In step S7 the processor 42 executes the secure URL 
5 generator module to generate a web page document including secure URL(s). In step S8 the 
processor 42 executes the communication module to transmit the web page document 
including the secure URL(s) to the WAD 12 via the network 18. In step S9 the method of 
Fig. 6 ends. 

5> Resource Distribution Subsystem ("RDS") and Related Methods 

10 In Fig. 7 the RDS 16 is shown in relative detail. As previously described, the RDS 

16 includes a web server 30 and a data storage unit 32. The web server 30 includes a 
processor 54, a memory 56, a communication interface unit 58, an mpnt device 60, and an 
output device 62. The memory 56 stores an operating system that is loaded and executed by 
the processor 54 to enable such processor to receive and transmit signals from and to the 

15 memory 56, the conmiunication interface unit 58, the input device 60, the ou^ut device 62, 
and the data stc^age unit 32 via the bus 64. The memory 56 also stores various program 
modules tiiat flie processor 42 executes in coordination with the operating system to control 
access to a resource requested by the user and/or WAD 12. More specifically, the memory 
56 stores an access right enforcer module, a secure caching module, a secure URL generator 

20 module, and a communication module. The RDS 16 also stores a secure content key 
database storing key data, and a resource access right database storing access right data that 
deJBnes the rights and liinitsofa WAD and/or user to access a resource. The conununication 
module is ^ecuted by the processor 54 to receive a request^for-resource signal including a 
URL with secure resource access right data fiom the WAD 12 via the network 18. The 

25 sigoal can be recdved by the communication interface unit 58 lising TCP/IP protocol, for 
example. The processor 34 receives such request signal from the communication inter&ce 
unit 58 over the bus 64 through execution of the communication module and operating 
system program. The access ri^ enforcer module is executed by the processor 54 to 
determine whether a user is authorized to access a resource designated in a request signal 

30 from a WAD 12* The processor's execution of the access right enforcer module causes such 
processor to generate a control signal supplied over the bus 64 to retrieve key data fiom the 
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memory 56. The processor 54 receives the key data from the memory over the bus 64, and 
uses the key data to verify the hashed or encrypted portion of the access rigjit data contained 
in the request-for-resource signal from the WAD 12. If the processor 54 determines that the 
user is not authorized to obtain the resource based on the decoded access right data, the 

5 processor 34 generates and transmits a denial-of-access signal to the WAD 12 by executing 
the communication module and operating system program to transmit such signal. More 
specifically, the processor 54 generates the denial-of-access signal and supplies such signal 
to the communication interface unit 58 over the bus 64. The processor 54 can generates the 
denial-of-access signal as an HTTP message that can be a standard "403 Forbidden" 

10 message, for example. The communication interfece unit 58 transmits the denial-of-access 
signal to the WAD 12 over the network 18, 

The secure caching module is executed by the processor 54 to retrieve a resource if 
the execution of the access right enforcer module detenoaines that access to the resource is 
pennitted for the requestmg WAD and/or user. The processor 54 generates a signal supplied 

15 to the data storage unit 32 via the bus 64. If the resource is present in the data storage unit 
32, the processor 54 retrieves the resource via the bus 64, Depending upon the nature of the 
resource, the processor 54 can load and execute the resource using its m^ory 56, Hie 
execution of such resource may cause generation of signals that are siq[)plied to the WAD 12 
via the network 18 using the communication interface unit 58 through execution of the 

20 communication module and operating system program. Alternatively, the resource can be 
data in which case the processor 54 executes its communication module and operating 
system program to supply such data to the WAD 12 via the communication interfece unit 58 
and network 18. 

Conversely, if the resource is not present in the data storage unit 32, the processor 54 
25 executes the secure caching module to generate a request-for-resource signal The processor 
54 supplies the request-for-resource signal to the coromunication interface unit 58 over the 
bus 64. The execution of the communication module and qperating system program by ttie 
processor 54 causes such signal to be supplied to the communication interfece xmit 58. The 
communication interface unit 58 transmits the request-for-resource signal to the RPS 14. 
30 The unit 58 can transmit the request-for-resource signal in TCP/IP protocol, for exan^le. In 
response to the request-for-resource signal, the RPS 14 determines if the RDS 16 is 
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authorized to host the resource. If not, the RPS 14 generates and transmits a denial-of- 
request-for-resource signal over the network 18 to the web server 30 of RDS 16. 
Conversely, if the RPS 14 determines that the RDS 16 is authorized to access the resource, 
the RPS 14 can encrypt the resource with key data pre-established for signals transmitted 

5 between the RPS 14 and the RDS 16. The RPS 14 transmits the resource signal to the RDS 
14 via the networic 18. The resource signal can be transmitted by the web server 24 in 
TCP/DP protocol The RDS 16 receives the resource signal at the communication interface 
unit 58. The processor 54 executes the communication module and operating system 
program to receive the resource signal from the communication interface unit 58 via the bus 

10 64. The processor 54 retrieves key data appropriate for the RPS 14 from the memory 56 via 
the bus 64. The processor 54 executes the secure caching module to decrypt the resource 
signal with the key data. The processor 54 transmits the decoded resource signal to the data 
storage unit 32 for storage. As previously described, the resource can be such as to be loaded 
and executed by the processor 54, or may be interactive in nature such as a server jqpplication 

15 that interacts witii a client 25>pKcation of tiie WAD 12, Alternatively, the resource can be a 
data file that is transmitted by the processor 54 to the WAD 12. The resource or signals 
derived therefrom can be encrypted before transmission and decrypted after receipt by the 
processor 54 and the WAD 12 so that flie resource or signals derived therefrom are not 
exposed to hacking or theft in transit over public network 1 8. 

20 Fig. 8 is a flowchart of processing performed by the web server 30, or more 

spedficalfcr, the processor 54. In Fig. 8 processing performed by the processor 54 begins in 
step SI. In step 82 flie communication intetfrice unit 58 receives the request-for-resource 
signal having the URL and secure resource access right data from the WAD 12 via flie 
network 18. The processor 54 executes flie communication module and operatmg system 

25 program to receive the request-for-resource-acoess signal from the communication inta&ce 
unit 58 via the bus 64, hi step S3 the processor 54 executes the access right enforcer module, 
which causes such process to retrieve key data &om the secure contmt key database of the 
memory 56 using the bus 64. In step S4 the processor 54 uses tibie key data to detemime 
whether the WAD and/or usct is authorized to access the resource using the resource access 

30 right data m the request-for-access signal from the WAD 12. In step S5 the processor 54 
determines whether the resource access right data indicates that the user is authorized to 
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access tfie resource. If not, in step S6 the processor 54 generates a signal indicating denial of 
access to the WAD 12. La step S7 the processor 54 executes the coxnHiunication module to 
transmit the denial-of-access signal to the WAD 12. Conveisely, if in step S5 the processor 
54 deterrdnes that tiie WAD 12 is authorized to access the resource, in step S8 the processor 
5 54 executes the secure caching module to determine whether the resource is presmt in the 
data storage unit 32. If not, in step S9 the processor 54 executes the secure caching module 
to generate a request-for-resource signal In step SIO the processor 54 executes ttie 
communication module and operating system program to transmit the request-for-resource 
signal to the communication interface unit 58 via the bus 64. The communication interface 

10 unit 58 transmits the request-for-resource signal over the network 18 to the RPS 14. In step 
SI 1 the web server 24 of the RPS 14 determines whether the RDS 16 is authorized to receive 
the resource. If not, the web server 26 generates a denial-of-access-to-resource signal and 
transmits such signal to the RDS 16 via the network 18. In step S12 the processor 54 
receives the denial-of-access-to-resource signal. Conversely, if the web server 24 of the RPS 

15 14 determines that access to the resource is authorized, such web server retrieves the 
resource 6om the data storage unit 26. The web server 24 executes its access right enforcer 
module, causing such web server to retrieve key data jfrom the secure content key database in 
die memory 44. the web server 24 uses the key data to encrypt the resource, and transmits 
the encrypted resource signal to the web server 30 of the RDS 16 via the network 18. The 

20 communication inter&ce unit 58 receives ite resource signal fiom the network 18. b step 
.813 the processor 54 executes the communication module and operating system prograni to 
receive the resource data &om the communication inter&ce unit 58 via the bus 64. After an 
affirmative deteimination in step S8 or after performance of step 813, in step S14, the 
processor 54 provides access to the resource for the WAD 12. The maimer of providing 

25 access to the resource depends upon its nature. If tbe resource is an application^ such access 
can be provided by loading and executing such resource implication with the processor 54 of 
the web server 30. Alternatively, if the resource is data, the resource can be provided by the 
processor 54 to the WAD 12 via transmission over tiie network 18. After performance of 
step S7 or step 814, processing performed by the processor 54 terminates in step 815 of Fig. 

30 8. 
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6. Secure Content Key Database 
The secure content key database is a data table or file hosted on the RPS 14 and/or 
RDS 16, or more specifically, the respective web servers 24, 30. The secure resource key 
database can be pre-defined initially and updated through secure signals transmitted from the 
5 web server 24 to the web server 30, 

As shown in Figs. 9A and 9B the database contains a list of one or more rows of data 
or records. The fields or columns and values associated with the data records are identified 
below. 
Key Data 

10 Each row or record includes hash and/or encryption/decryption key data associated 

wifli a resource provider. The key data can be a 128-bit or 256-bit key, for example, which 
are industry standard key sizes. The encryption key data is indicated in hexadecimal format, 
ie., binary numbeis 0000 - 1 1 1 1 correspond to hexadecimal numerals 0 - F. 
URL/Resource provider Identification Data 

15 It is possible that the web s^ers 24, 30 host resources of more than one resource 

provider on the netwoik 18. Accordingly, the resource provider identification data permits 
the web senrers 24, 30 to identify and distinguish between different resource providers. For 
example, the web server 30 can use the URL of a resource provider to retrieve a resource 
fiom such provider in the event the web server 30 determines that it does not already host the 

20 resource. A "0" value in this field can be used to indicate that fhe web server 30 hosts the 
resource. 

Validate Web Access Device / User Reouest 

This field identifies to the web servers 24, 30 whether the key is to be used to validate 

a WAD /user request. If tiiis value is set to "1" the key is used to validate requests firom the 
25 WAD 12, and if flie value is set to "0" the key is not used to validate requests. 

Retrieve Resource Data 

This field is used to indicate to the web servers 24, 30 wheUier its associated key data 

is for use in retrieving a resource fixmi respective data storage units 26, 32. If the value of 

diis field is set to "1" then fhe associated key data is used to validate a request to retrieve a 
30 resource. Conversely, if this value is "0" then the associated key data is not used to validate 

such request. 
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Start Pate/Timr Data 

This jGield indicates the start date and time over which corresponding key data is 
valid. For example, the format of the field can be "month.day.year'* to specify ihe date, and 
"hourjninute.teQth-of-secondJiimdredth-of-second" to specify the time. Accordingly, 
5 "5,29.2000" means *May 29, 2000" and "23:00:00.00" means "11:00:00.00PM." Such start 
date/time data can alternatively be represented in "epoch time" which is well known to those 
oidinary skill in the art, and refers to tile number of seconds elapsed since the beginning of 
January 1, 1970. 
End Pate/Time Data 

10 This field indicates the end date and time beyond which the key data is no longer 

valid The format of the field can be similar to that of the "Start Dat^ime Data" field. 

The Start Date/Time Data and Bsid Date/Time Data fields can be used to define a 
time period over which the key data is valid. Subscriptions to a resource can use key data 
valid for limited periods of time, 

15 Like-span Data 

This field can be used to determine the life-span of its associated key. The life-span 
data can be defined as a certain length of time from a particular start date/time. Hence, in 
this example, the life-span data can be defined as the start date/time data *'529^000 
23:00:00.00" and life-span data of "360:00:00.00". 

20 Key Index DATA 

TMs field identifies the index associated with its correspondiiig key data, ft identifies 
keys used to control access to a distributed resource. This field can be set to a value within 
the range of values for all keys recognized for communication between the WAD 12 and the 
RFS 14 and/or RDS 16. This field can also be set to "0" to uidicate that the associated key is 

25 the only key used to control and secure resource access in communications between the 
WAD 12 and the RPS 14 and/or KDS 16. For example, yspoa receiving a request for access 
to a resource, the web server 30 of RPS 1 6 can use the key index data in the request signal to 
retrieve tiie ^propriate key for use m validating the request. Alternatively, the RPS 16 can 
use a single key to validate each resource request, in which case no key index need be 

30 specified in the request signal. 
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Hash IDENTIFIER DATA 

This field identifies a hash algorithm utilized by the WAD 12 and/or web servers 24, 
30 to communicate with one another by signals transmitted over network 18. As previously 
described, the hash algorithm can be one of many diflferent algorithms including SHA-1 

5 published by the United States Goveniment, MD5 (Message Digest Algorithm 5) produced 
by RSA Laboratories, Iqc, Tiger, RIPEMD-160, DES, 3-DES, and others. A hash algorithm 
g«ieraUy has the properties that: (1) different data do not map to the same digest upon 
application of a digest algorithm; and (2) the digest does not reveal anything about the 
particular digest algorithm or data that was used to generate it In addition, many digest 

10 algorithms generate a fixed length data string regardless of the number of bits in the hashed 
data. This feature generally permits the hashed data to Jbe more readily incorporated into a 
message format for transmission as a signal by the WAD 12> the web server 24, and/or the 
web server 30 over the network 18. 
Encryption Model 

15 This field indicates the encryption strategy to be used to generate encrypted resource 

access rigjht data. For example, the ©acryption strategy can be one-way, two-way, etc. 

Encryption Algorithm 

This field idoatifies the encryption algorithm to be used to generate encrypted 

resource access right data. The encryption algorithm can be public key/private key or private 
20 key algoritiuns which are well-known to fliose of ordinary skill in this technology. 

Format Feeij>s 

This field indicates the number of format fields contained in a data record of the 
database. It can be used to indicate to tiie web servers 24, 30 the number of fields esqpected 
to be present in a signal trananittedfi^m the WAD 12 to the web serva: 30. 
25 7, R3ES0URCE ACCESS Right Database 

The resource access rigjbt database defines the rights associated with a particular 
WAD and/or a user. In the exemplary embodiment of Fig. 9C the resource access right 
datd)ase provides Ihe access rights associated with IP addresses. The following fields can be 
included in the resource access ri^t database. 
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Authorized IP Address Range 

Data in this field indicates IP addresses of WADs authorized to obtain access ito a 
resource. The address ranges can be defined in twrns of four 256-bit numbers as is now 
standard on the Internet. Of course, additional addressing schemes now existing or that may 
5 be developed in the fixture can be used to define the IP addresses of WADs authorized to 
access the resource. The field can also be in pneumonic form, i.e., 
"www.xxxxxxxxx.com/yyyy/yyyy*' where the "x"'s indicate a domain name and the "y^s 
. indicate a field pafti to the data storage location of the resource, which can be resolved into 
an IP address by a stored mapping, for example. 
10 IP Address of Resource Provider Server 

This field indicates the IP address of the web server 24 of the RPS 14 ttiat initially 
hosts the resource imtil distributed to one or more RDS 16. This field can be in mnemonic 
form. 

Retrieval Key Data 

15 This field indicates the key data used to encrypt or decrypt data transmitted between 

fte web servers 24, 30 of the RPS 14 and/or RDS 16. For example, the key data can be used 
by the web server 30 of the RDS 16 to decrypt the resource transmitted fix>m the RPS 14 to 
fte RDS 16 in re^onse to a request-for-resource signal generated by a WAD. 
T.TFE-SPAN Data for Data Access of URL 

20 This field can contain the start date/time and span of titrne firom such start date/time 

over which access to the resource is pemiitted the WAD or user thereof. This field can be 
used to control access to the resource to only authorized paying subscribers, for example. 
MAXPtfOM Reference Data 

This field represents the maximum number of times a nser and/or WAD may access a 

25 resource- The web serv^ 30 can track the number of accesses made by the WAD, in which 
case the mflyimnnrt reference data can be transmitted m a secure URL firom ttie web server 24 
to the wd) server 30 via the WAD 12. Alternatively, the wcib server 24 can track the number 
of accesses to the resource by the WAD by the web server 30 noting the server 24 
each time the WAD seeks access to the resource. The web servers 24 and/or 30 can store 

30 this data along with reference count data that is mitially set to "0" and incremented each time 
the WAD 12 accesses the resource. If the web servers 24 and/or 30 determine that the WAD 
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12 has exceeded the maximum number of permitted accesses to the resource, such web 
servers can be programmed to prohibit the WAD 12 fiom ftolher accessing the resource. 
The web servers 24 and/or 30 can perform this function by tracking the number of accesses 
to the resource using a particular secure URL. 

5 Reference count data 

This field contains data indicating the number of times the resource has been 
accessed by a WAD and/or user. It is compared against corresponding maximum reference 
data to determine whether access to the data remains authorized. It should be understood 
that the reference count data is not stored in the URL, but instead is maintained by the web 

10 servers 24 and/or 30. 

8. Secure URL, the Secure URL Generator Module, anp Related Methods 
The secure URL generator module functions to generate a URL having resource 
access right data starting from a URL. The URL with secure resource access right data can 
be referred to as a "secure URL". Figs. lOA and lOB represent a "formatted path" technique 

15. for generating a secure URL, and Figs. UA and IIB represent a "appended argument" 
approach to gen^ting a secure URL. In the formatted path approach to encoding resource 
access right data with the UKL, an original URL: 

ht^://www,content-server.coni/pathl/path2/j51e.ext 

20 

becomes 

http:/Avww.contemt-server.com/securejresoun:e_accessjig^^^ 

25 Thus, the resource access rigjit data becomes a part of the file path leading to the resource 
requested by the WAD 12; The appended argument approach takes a different form: 

ht^://ww.content-server.com^&iyi)ath2/file.ext?secui^^^ 

Hence the appended argument approach appends the secure resource access right data to the 
30 end of the URL. These axe but two examples of techniques for generating a secure URL and 
others may occur to those skilled in this tedmology, 
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Jn Figs. lOA and lOB the fonn of flie unsecure URL includes a header field "http://**, 
a destination field "www.content-server.com", a data request field(s) "pathl/patii2/file.ext" in 
which "pafhl" and "path 2" are paths identifying the location of a resource file, "file" is the 
resource file itself; and ".ext" is an extension such as ".txt", ".doc", jpg", ".tif, *^bmp^ 
5 ".mpg", ".wav", ".avi", etc. , that identifies the nature of the file. The separator is a character 
to distinguish the path and file name from the remainder of the fields. In this case the 
separator is "?". The Internet protocol (ff) address indicator "ip=" signifies to the web server 
30 the IP address of the WAD 12 generating the request-for-access-to-resource signal. In 
this example, the IP address of the WAD 12 is "1.2.3.4". The end IP address and the 

10 beginning of the hash indicator field is designated by a separator, in this case "&". The 
unsecure URL includes a hash indicator field "hash=" having a value 
"ACD54CD3D8ECA892ACB34E4B5D1C8C38" in this example. The hash is the result of 
the hash algorithm applied to at least the IP address but possibly other fields defining the 
resource access right , data or possibly secure content key data included in the secure URL. 

15 Such fields have been previously described in connection with the resource access right 
database and the secure cont^t key database. 

Fig. IIA is an exemplary method for genmating a secure URL having resource 
access right data. This method can be perfomied by the web server 24 of the RDS 14 to 
g^erate secure resource access right data combined witii a respective URL in a web page 

20 document requested by a user of a WAD 12. to step SI of Fig. 1 1 A the header data (e.g., 
•Tittp://" or "fip:/r), fho destination JP address (i.e., the IP address of the web server 30) and 
data fields (i.e., the file path to the resource), are combined to generate an unsecure or basic 
URL. Step SI can be performed by a URL assembler of the secure URL generator module. 
In step S2 of Fig, llA the unsecure URL, the key data, the IP address of the WAD 12, and 

25 the resource access ri^t data, are combined to form an unsecure URL with unsecure 
resource access rigjit data. The key data can be retrieved fiom the secure resource key 
database using the corresponding URL in the web page document as a reference to retrieve 
this data. The resource access rigiht data can be retrieved from its database using the IP 
address of the WAD 12 and/or the user name and password established througfh a log-in 

30 procedure, for example. As previously described, the resource access right data can include 
authorized ff address range, IP address of resource provider server, retrieval key data, life- 
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spm data for data access for URL, and maximum reference data, for example. In stg) S2 the 
unseciure URL having resource access right data with appended key data is hashed using a 
hash generator of the secure URL generator modnle to generate hash data that inchides 
resource access right data. In step S3 flie unsecure URL generated in step SI, data for any 
5 visible fields that are to be included in the secure URL and intended to be freely accessible m 
transmission over the network 18, and hash data including the resource access right data, are 
combined together and encoded into a form that can be handled by a server to generate the 
secure URL with resource access right data. Step S3 can be performed by a message 
assembler of the secure URL genemtor module. 

10 The RPS 14 incorporates the secure URL(s) into a web page dociraient for 

transmission to the requesting WAD 12 and/or user. As shown in Fig. 1 IB the secure URL 
generator module can include a web page assembler receiving the secure URL(s) with secure 
resource access right data and other web page elements such as HTML code vnth applets, 
image, text, sound, and/or video files or clips, etc. The web page assembler module 

15 combines the elemaits of the w^ page document with the secure URL. The RPS 14 can 
transmit the resulting web page document with secure URL to the WAD 12. 

The hash generator of the secure URL generator module can generate the hash data 
including the resource access right data using a hash algori&m such as SHA-1 or DES upon 
selected data contained within the secure URL The specific hash or encryption scheme used 

20 to hash or encrypt resource access right data is not particularly in]|)ortant to the invention, but 
it is generally desirable that: 

(1) both the secure URL generator module and the rights management enforcer 
module use die same hash or encryption format and encryption/decryption algorithm; 

(2) the IP address and an indication of the hash or encryption key if there are 
25 altCTiatives be included in the resource access ri^t data; and 

(3) the hash or aioyption key not be visible as part of the unenoypted data in the 
secure URL. 

Fig. 12 is a rnethod for decodixigresoun^e access right data within a secure The 
method can be performed by the web server 30 of tiie RDS 16 upon receiving a request 
30 signal fiom the WAD 12 including the secure URL with resource access right data. In step 
SI of Fig. 12 the authentication module receives the data field(s) indicating a path to the data 
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Storage location of the resoiirce. The aufhenticadon module also receives hash data 
representing the portion of the resource access right data hashed by the RPS 14. hi Ihis 
example, the hashed data is the result of hashing the IP address. The authentication module 
further includes hash identifier data such as the hash index that indicates the hash algorithm 
5 used by the RPS 14 to produce the hash data. The authentication module also receives the 
resource access right data including the IP address of the WAD, The resource access right 
data can be in either encrypted, visible, or hybrid fomi. The authentication module can 
perform a check of the format of the secure URL and resource access right data to ensure 
they have proper form readable by the web server 30 of the RDS 16. If the secure URL does 

10 not have the proper format, the authentication module passes the resource request to the 
request termination processing module. The authentication module authenticates that the 
WAD and/or user generated the request to access a resource. For example, the 
authentication module can perform this fimction by compaiing the IP address within the 
resource access right data to the IP address included in the header of the HTTP formatted 

15 message to ensure that they are the same IP address. If the IP address match, the 
authentication module passes the authenticated data to the hash verification module. If the IP 
address do not match, the auth^tication module passes the resource requ^ to the request 
termination processing module. 

If the resource request fi-om the WAD is authenticated, the bash verification module 

20 uses the URL of the resource request to look-up the key data appropriate to use with the RPS 
14. The corresponding key data can be retrieved and used by die web server 30 to deorypt 
resource access or other data within the secure URL. K there is more than one key used 
with the URL of the RPS 14, key index data will be iacluded in die secure URL by die RPS 
14. This key uidex data can be eictracted fiom the secure URL and used by the hash 

25 verification module to retrieve the ^ropriate key. The hash verification module can also 
verify die right to use the key using data in the secure content key database. For exanQ>le» the 
hash verification module can comparc start date/tune, end date/time, and/or life-span data 
with the date/tune of the request to detemoine whether the key is valid* If not, the hash 
verification module passes the resource request to the request tenmnation processing 

30 module. The hash verification module can ialso determine whether file WAD and/or user are 
authorized to access die requested resource by using the hash identifier data to perform a 
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corresponding hash algorithm on all or a portion of the resource access right data. More 
specifically, the hash verification modiile spends the key data to the resource access ri^t 
data and perfomis the appropriate hash algorithm on this data to produce hash data. If the 
hash data produced hy the authentication module matches the hash data in the secure UKL in 

. 5 the resource request message jfrom the WAD 12, the hash verification module passes the 
verified data to the resource access right verification module. Conversely, if the hash data do 
not match, the hash verification module passes the resource request to the requiting 
tennination processing module. 

If the hash verification module verifies the right to use the key and matches the 

10 Imsh/enciyption data, the resource access right verification module determines whether 
access to the resource is authorized. Resource authorization can be performed by checking 
the life-span data from the resource access right database, against the date/time of the 
resource request Resource authorization can also be performed by incrementing the 
reference count data in the resource access right database and comparing the incremented 

15 value witii the maximum reference data. If the refer«ice count data is less than the 
maximum reference data, the access right verification module passes the resource request to 
the resource handler. Conversely, if access to the resource is not authorized, for example, 
due to expiration of the time permitted to access the resource or due to exceeding flie 
Tpayiiniini allowed number of accesses to the resource, the access right verification module 

20 passes the resource request to the request termmation processing module. The request 
termination processing module is executed by tiie web server 30 to transmit notification to 
the WAD and/or usot that the resource request has been denied, 

XJpon receiving a resource request from the access right verification module, the 
resource handler retrieves the resource from either the data storage unit 26 or 32. If the 

25 resource had been previously requested, the data storage unit 32 stores the resource. 
However, if the resource request has been made for the first time, tiie web server 30 of the 
RDS 16 retrieves the resource from the web server 24 of the RPS 14. The web server 30 
execute the resource handler module to provide access to the resource fat tiie requesting 
WAD and/or user. 

30 In Fig. 12, the secure URL having secure resource access right data can be provided 

to the access right management enforcer module via the communication module as shown in 
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Fig. 5. The authentication module, hash verification module, and access right module of Fig. 
12 can be included in the access right enforcer module of Fig, 5. The resource handler of 
Fig. 12 can be included in the secure caching module of Fig. 5. 

Fig. 13A is a flowchart of a method for authenticating an IP address of a WAD, The 

5 method can be performed by the web server 30 in executmg the authentication module, for 
exan^le. In step SI the method begins. In step S2 the IP address is extracted from resource 
access right data included ha the securc URL of a resource request. In step S3 the web server 
30 compares the IP address from the resource access right data with the source IP address m 
the HTTP message header of the secure URL message. In step S4 a determination is made to 

10 establish whether the IP address in the resource access right data and the header match. If so, 
in step S5, the resource request is passed to the resource handler module. Conversely, if the 
determmation in step S4 is negative, in step S6 the resource request is passed to the resource 
request termination processing mobile to terminate the resource request. After performance 
of step S6 or S9, the method of Fig. ISA eiwis in step S7. 

15 Fig. 13B is a flowchart of processmg performed to check the field format of a secure 

URL request The method can be p^ormed by the web server 30 in execution of the 
authentication module, hi step SI the method of Fig. 13B begms. In step S2 field separators 
are located in the secure URL string. In step S3 parameter data defining the format of the 
secure URL striuDg is retrieved by the web server 30 from its memory. This data can indicate 

20 field separators, tnaxitnum number of characters for each field, and a check for characters 
tiiat are not allowed within a field data string. In step S4 the data delmeated by field 
separators m the secure URL string is compared with the parameter data. In step S5 a 
detemiination is made to establish whether the field format is correct based on the 
comparison of step S4. if so, in step S6 the secure URL string is passed to the hash 

25 verification module. Conversely, if the field format is determined not to be prop^ in stq) 
S5, the resource request is passed to the resource message termmation processing module for 
termination of the resource request. After performance of steps S6 or S7, processing 
performed by flie web server 30 terminates in step S8. 

Fig» 13C is a flowchart of processing performed by the hash verification module to 

30 determine whether access to the resource is authorized. In step SI the mefliod of Fig. 13C 
begins. In step S2 key validation data is retrieved from the secure content key database using 
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the IP address of fhe WAD. The key validation data can include the start date/time, end 
date/time, or life-span data for die key. This can be done by accessing a log to determine 
when the request was made, or by checking die date/time at performance of step S3. In st^ 
S4 a determination is made to establish whether the key is valid based on the determination 
'5 of step S3. If so, m step S5 the resource request is passed to hash verification processing. 
Conversely, if the determination in step S4 is not valid, the method proceeds to step S6 for 
performance of request message teraiination processing. After performance of step S5 or 86, 
themetiiod of Fig. 13C terminates in step S7 of Fig. 130. 

Fig. 1 3D is a flowchart of processing performed to verify hash data included within 

10 the secure URL of the resource request message to ensure that the resource has not been 
corrupted in transmission or tampered with. In step SI the method of Fig. 13D begins. In 
step S2 a key is retrieved jfrom the secure content key database based on the JP address of the 
WAD requesting access to a resource. In step S3 the resource access right data and hash data 
.. are decrypted with the key. Steps 82 and S3 are optional steps and may be omitted if 

15 encryption of resource access right data is not required during transmission over the network 
18. In step S4 hash data and resource access right data are extracted from the secure URL of 
the resource request. In step S5 a hash is performed on the extracted resource access right 
data. Jn step S6 a determination is made to establish whether the produced hash data 
matches tiiie hash data received in the secure URL. If the hash data matches, processing 

20 proceeds to step S7 in which the resoturce request is passed to the access right verification 
module. Conversely, if the hash data do^ not match in step S6, processing proceeds to step 
. S8 in which termination processing is executed to terminate the resource request After 
performance of either step 87 or step S8, the method of Fig. 13D tenninates in step S9. 

Fig. 13E is a flowchart of a method of verifying that the requesting WAD or user is 

25 authorized to access a resource. In step SI the method of Fig. 13E begins. In step S2 
resource access right data is retrieved fiom die resource access right database using the IP 
address of the WAD. The resource access right data can optionally mclude an authorized IP 
address or address range authorized to access a resource, life-span data defining the period of 
time over which the resource can be accessed by the requestor, and maximum reference data 

30 indicating the maximum number of tim^ a WAD or user can access a resource, IhstepSSa 
deternunafion is made to estabUshwhedier fhe WAD is authorized to access If 
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SO, in step S4 the secure URL of tiie resource request is passed to flie resource handler. 
Conversely, if the detennination in step S3 is negative, in step S5 the resource request 
message is terminatei After performance of either step S4 or step S5, the method of Fig. 
13E terminates in step S6. 
5 Fig* 13F is a flowchart of processing performed by the processor 54 of the web server 

30. The processing is perfonned to determine whether the request sigaal from the WAD 12 
has been made within the time permitted for accessing the resource as established by the RPS 
12, The method of Fig. 13F can be performed by tiie access right enforcer module executed 
by the processor 54. In step SI of Fig. 13F processing performed by the processor 54 begms 

10 in step SI. In step S2 tiie processor 54 logs the date and time of receipt of the request-for- 
r^ource signal from the WAD 12. In step S3 the processor 54 compares the start date/time 
of receipt of the request-for-resource sigaal with the start date/time data in the decoded 
resource access right data. In step S4 the processor 54 determines whether the dat^time of 
receipt of the request-for-resource sigaal is greater than the start date/time data in the 

15 resource access rigjit data. If so, in step S5 the processor 54 compares the date and time of 
receipt of the request-for resource signal with the end date/time data contained in the 
resource access right data. In step S6 the processor 54 determines whether the date and time 
of receipt of the request-for-resource signal is greater than the end date/time data in the 
resource request data. If the det^inination m steps 84 or S6 are negative, the processor 54 

20 denies access to ttie resource in step S7» The processor 54 thus prohibits the WAD 12 from 
accessing the resource. Conversely, if the det^mination in step S6 is afSnnativ^ in step S8 
the processor 54 provides acc^ to the resource. After performance of step S7 or 88 
processmg performed by the processor 54 terminates in step S9 of Fig. 15. 

Fig. 13G is a flowchart of processing performed by the processor 54 of the web 

25 serv^ 30 to determine whether the WAD 12 and/or user thereof is authorized to access the 
resource on the start date/time data contained in the decoded resource acc^ right data 
received in the request-for-resource signal of the WAD 12. The method of Fig. 16 can be 
poformed by the access right enforcer module executed by the processor 54. In step 81 of 
Fig. 13G processing performed by the processor 54 begins. In step 82 the processor 54 logs 

30 the date/time of receipt of the request-for-access signal from tibte WAD 12. In step S3 the 
processor 54 compares the start date/time of receipt of the request-for-resource signal with 
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the Start date/time data contained within the decoded resonice access right data. In step S4 
the processor 54 detemiines whether the date and time of receipt of the request-for-resource 
signal is greater than the date and time indicated in the decoded resource access rig^t data. If 
the determination in step S4 is afSnnative, in step S5 tiie processor 54 adds the start 
5 date/time in the decoded resource access right data to the life-span data contained in the 
decoded resource access right data* hi step S6 the processor 54 compares the sum of the date 
and time in the decoded resource access right data and Ufe-span data, with the data and time 
of receipt of the request-for-access signal, hi step S7 the processor 54 determines whether 
the date and time of the receipt of request-for-resource signal is greater than the sum of the 

10 start date and time data and the life-span data. If the determinations in steps S4 or S7 are 
afiBrmative, in step S8 tiie processor 54 denies access to the resource to the WAD 12. 
Conversely, if the detemiination in step S7 is afl&mative, in step S9 the processor 54 
provides access to the resource* After performance of either step S8 or S9 processing 
performed by the processor 54 temiinates in step SI 0. 

15 Fig. 13H is a flowchart of a method for verifying whether WAD and/or user are 

permitted to access a resource. The method of Fig. 13H can be performed by the web server 
30 of the RDS 16, for example. In step SI the method of Fig. 13H begins. In step S2 
maximum reference data and reference count data are retrieved £rom the resource access 
right database, hi . step S3 tiie reference count data is incremented, hi step S4 the 

20 incremented reference count data is compared with the maximum reference data. In step SS 
a detennination is made to establish whether the incremented reference count data is greater 
than or equal to the tp^xif"™ reference count data. If the detennination in step S5 is 
a£Grmative, in step S6, access to the resource is denied the requesting WAD through request 
termination processing. Conversely, if the detemunation in step S5 is negative^ processing 

25 proceeds to step S7 in which the incremented reference count data is stored in the resource 
access right database. In step S8 access is provided to the resource. After performance of 
ei&er step S6 or S8, the method of Fig. 13H terminates in step S9. 

Fig. 131 is a flowchart of a method for deteraiining whether a WAD is authorized to 
access a resource. The method of Fig. 131 can be perfoimed by the web server 30. In step 

30 SI the metihod of Fig. 131 begms. hi step S2 a detennmation is made to establi^ whether 
flie IP address of the web access device is within the authorized IP address range usmg the 
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resource access right database. Li stq> S3 a determination is made to establish whether the 
IP address of the web access device is within authorized IP address range. If the 
determination in step S3 is negative, in step S4 access to file resource is demed through 
resource request termination processing. Conversely, if the determination in step S3 is 

5 affirmative, in step S5 access to the resource is provided. After performance of step S4 or 85 
the method of Figure 131 ends in step S6. 

. Assuming that access to the resource is permitted by the access right enforcer module 
of the web server 30, the secure caching module of the web server 30 is used to retrieve 
resource data and generate a message including the requested resource. In Fig. 14 the 

10 resource can be in the form of data such as text, image(s), and/or applet(s) or complete web 
page document executable by the WAD 12 using its browser application. Alternatively, the 
resource data can be a program or "plug-in" module downloaded firom the web server 30 to 
the WAD 12 for execution thereon. In step SI of Fig. 14 a resource retriever of the secure 
caching module the data fields within the secure URL received firom the WAD 12 to retrieve 

15 the resource , data ftom the data storage unit 32. The data storage unit 32 si^phes the 
resource data to the message assembler of the secure caching module. In step S2 of Fig. 14 
the header fix)m the secure URL message received jftom the WAD 1 2 is combined with the IP 
address of the WAD and the resource data contained in the data storage unit 32 to produce 
the message having resource data. The processor 54 can call the communication module 

20 stored in its memory to transmit the message in the form of a signal to the WAD 12 via the 
network 18. 

Fig. 15 pertains to the processing performed by processor 54 in the case m which the 
resource data is a server application. The resource retriever receives the data indicating the 
result of the con5)arison fiom step S2 in Fig. 15 and the data fields fix>m the secure URL 

25 received from the WAD 12. The resource retrieve uses this data and the data fields to 
retrieve a server apphcation resource &om the data storage unit 32. In step S2 the loader / 
launcher of the secure caching module is executed by the processor 54 to load the server 
^Hcation into the memory 56, and to launch the processor 54 to execute the server 
application. After launch the server application can interact with the browser or cKent 

30 application of the WAD 12 optionally based on input fiom the user. 
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Fig. 16 is an exen[5)laiy view demonstrating conceptually how a resource distribution 
network can be built with the disclosed system. The RPS 14 effectively controls distribution 
through the use of RDS 16 positioned m different locations wiihm the geographic area 
served by the system. Requests for web page documents can be served by the RPS 14. 
5 Some or all requests for resources referenced by secure URLs within the web page 
documents distributed to the WADs 12 are serviced by RDS 16, By assigning RDSs 16 to 
serve WADs 12 that are relatively close in terms of transmission path, the WADs 12 can 
obtain relatively fast access to requested resources if authorized to receive them. 

The many features and advantages of the present invention are ^parent from the 

10 detailed specification and thus, it is intended by the appended claims to cover all such 
features and advantages of the described system, subsystem, devices, and methods which 
follow in the true spirit and scope of the invention. Further, since nmnerous modifications 
and changes will readily occur to those of ordinary skill in the art, it is not desired to limit the 
invention to the exact construction and operation illustrated and described. Accordingly, all 

15 suitable modifications and equivalents may be resorted to as felling within the scope of the 
invention. 

Industrial Appugabslity 
The disclosed methods, systems, subsystems, and apparatuses have widespread 
application in distribution via public network of content such as computer program(s)^ 

20 applet(s), text file(s), and/or image file(s), for Kcanq>la The disclosed methods, systems, 
subsystems, and apparatuses can be applied to Internet subscription services for electronic 
publications, e-zines, periodicals, nnages, video, graphics, or other forms of content 
distribution on a public network. The methods, systems, subsystems, and apparatuses also 
have {applicability to a broad range of websites offering products or service over the Memet, 

25 such as btemet s^ce providers (ESPs), directories, portals, search engine providers, 
q)plication service providers (ASFs), e-commerce websites, aiiction wd}sit6S, etc. The 
disclosed invention methods, systems, subsystems, and ^aratuses thus have widespread 
application in numerous industries. 
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Claims 

1 . A method characterized by the steps of: 

(a) generating hash data based on at least one of a universal resource 
locator (URL) of a resource, resource access right data defining restriction(s) on a web access 
device (WAD) and/or user thereof to access the resource, and an Internet protocol (IP) 
address of the WAD; and 

(b) combining the hash data, URL, and resource access right data in a web 

page. 

2. A method as claimed in claim 1 further characterized by the step of: 

(c) transmitting the wd) page docummt mcluding the secure URL to the 
WAD in response to a request for the web page document from the WAD. 

3. A method as claimed in claim 1 wherein the hash data is further generated 
based on key data. 

4. A method as claimed in claim 3 wherein steps (a) - (c) are performed at a 
resource provider subsystem (KDSX the method further characterized by the step of: 

(c) transmitting the key data 6om the RPS to a resource distribution 
subsystem (KDS) hostmg the resouice so that, if the secure URL is activated by the web 
access device to generate a request for ttie resource to the RDS, the RDS can verify tiiat the 
resource access ri^t data has not been modified other than by the RPS. 

5. A method as claimed in claim 1 wherein the resource access rigjit data 
includes at least one of: 

1) an authorized Memet protocol QP) address or IP address range; 

2) life-span data indicatmg the lif©-span indicating a time period over 
which requests for accessmg a resource are valid; and/or 

3) mavinnim reference data indicating a maximum number of times a 
web access device and/or us^r thereof can access a resource. 
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6 . A method characterized by the steps of: 
at a resource provider subsystem (RPS), 

(a) receiving a request for a web page from a web access device via a 
network, the request includmg a network address of the web access device; 
5 (b) determining resource access right data for the web access device 

and/or a user thereof, the resource access right data defining restriction(s) for the web access 
device and/ox user thereof to access a resource; 

(c) securing a universal resource locator (URL) for a r^ource by 
generating hash data based on at least one of the URL, a network address of the web access 

10 device, and/or resource access right data, and combining the URL, resource access right data, 
and hash data together in the web page; and 

(d) transmitting the web page having the secure URL to the web access 
device via the network in response to the request received in step (a) from the web access 

. device. 

15 7. A method as claimed in claim 6 wherein the hash data is generated further 

using key data corresponding to the web access device and/or user thereoi^ the method 
further characterized by the step of: 

(e) transmitting key data corresponding to the web access device and/or 
user thereof to a resoimje distribution subsystem (RDS) hosting the resource so that, if the 

20 secure URL is activated by the web access device to generate a request for the resource to the 
RDS, the RDS can verify that the resource access right data has not been modified other than 
bytheRPS. 

8. A method as claimed in claim 6 wherein the network address of the web 
access device is an Internet protocol (IP) address. 
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9, A method characterized by the steps of: 

(a) receiving a signal requesting a web page document from a wd? access 
device (WAD), the signal mcluding an Memet protocol (IP) address of the WAD; 

(b) retrieving data for the web page document including a universal 
5 resource locator (URL) of a docum^t referenced in the web page document; 

(c) retrieving resource access right data for the URL using the IP address 
of the web access device and/or user name and password established through a log-in 
procedure; 

(d) generating hash and/or encrypted data to generate secure resource 

10 access right data; 

(e) combining the resource access right data with the respective URL to 

generate a secure URL; and 

(f) generating the web page document including the secure URL; and 

(g) transmitting the secure URL to the WAD. 
15 10. A method characterized by the step of: 

at a web access device (WAD), 

(a) transmitting a signal requesting a web page document to a resource 
provider subsystem (RPS); and 

(b) receiving the web page document having a secure universal resource 
20 locator (URL) with hash data, URL, and resource access right data, in response to the 

request. 

11. A method as claimed in claim 10 further characterized by the step of: 

(c) activating flie secure URL with the WAD to transmit a signal 
requesting access to a resource designated by the URL to a resource distribution subsystem 

25 (RDS); and 

(d) accessing the resource with ttie WAD if the RDS determines that 
access to Ae resource is authorized based on the hash data and resource access rigfht data 
contained in the request signal. 
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12. A mefliod characterized by the steps of: 

(a) at a web access device (WAD), generating and transmitting a request 
for a web page document to a resonice provide* subsystem (RPS); 

(b) receivmg the requested web page document having a secure universal 
5 resource locator (URL) with secured resource access ri^t data from the resource provider 

subsystem (RPS); 

(c) executing a browser plication and web page document with the 
WAD to generate and transmit a signal to request a resource distribution subsystem (RDS) to 
provide access to a resource identified by the secure URL, the request signal including the 

10 URL and secure resource access right data; and 

(d) if access to the resource is permitted by the RDS, accessing the 
resource with the WAD. 

13. A method as claimed in claim 12 wherein the step (d) is characterized by the 
substeps of: 

15 (dl) receiving at flie WAD resource data from flie RDS; 

(d2) storing the resource data in memory of the WAD; 

(d3) executing an application with tibie WAD based on the resource data to 
generate a signal; and 

(d4) generating a display with the WAD based on the signal generated in 
20 flie substep (d3), 

14. A method as claimed in claim 12 wherein ttie step (d) is characterized by the 
substeps of: 

(dl) receiving a program module resource from the RDS; 
(d2) loading the program module resource into memory of the WAD; 
25 (d3) executing the program module resource with the BAD to generate a 

signal; 

(d4) storing the signal(s) in memory; and 

(d5) generatmg a display with the WAD based on the signal gmerated in 
the substep (d4). 
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15. A method as claimed in claim 12 wherein the step (d) is characterized by the 
substeps of: 

(dl) receiving at the WAD via the network a signal from the KDS 
generated based on execution of a server application by the RDS; 
5 (d2) storing ttie received signal in the memory of the WAD; 

(d3) genorating with the WAD a display signal based on the signal received 
inthesubstep(dl); 

(d4) generating a display with the WAD based on the display signal; 
(d5) executing a client application with the WAD to generate a signal 
10 based on the signal from the RDS; and 

(d6) transmitting the signal(s) to the RDS via the network, 

16. A method as claimed in claim 12 further characterized by the step of: 

(d7) receiving ii^ut data at the WAD from a user, the cUent application 
executed in step (d5) based on the input data. 
15 17. A method characterized by the steps of: 

at a resource distribution subsystem (ELDS), 

(a) receiving a signal requesting access to a resource from a web access 
device (WAD), the signal including at least a universal resource locator (URL), resource 
access nglat data, and hash data; 
20 (b) verifying fliat the resource access right data as set by a resource 

• provider subsystem (RPS) has not been changed, using the hash data; 

(c) if the verifying establishes that the resource access ri^t data has not 
been changed, determining whether access to the resoiux^e is permitted to the WAD and/or 
user thereof based on the resource access right data; and 
25 (d) if the resource access right data indicates that the WAD and/or user 

diereof is authorized to access the resource, permitting access to the resource to the WAD 
and/or user thereof 
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18. A metiiod as claimed in claim 17 whearein the resource access ri^t data 
includes at least one of: 

1) an aafhorized fctemet protocol (D?) address or IP addr^s range; 

2) life-span data indicating the life-span indicating a time period over 
5 which requests for accessing a resoiirce are valid; and 

3) maximum reference data indicating a maximum number of times a 
web access device and/or user thereof can access a resource. 

19. A method as claimed in claim 17 wherein the hash data is generated based on 
the URL, resource access right data, and key data, the method further characterized by the 

10 step of: 

(e) receiving key data ftom the RPS for use in verifymg in step (b) that 
the resource access right data has not changed from establishment by the RPS , 

20. A method as claimed in claim 17 wherein the key data includes a key and 
optionally at least one of: 

15 1) a second URL identifying the RPS; 

2) start date/time data identifying a date and time at which a key is valid; 

3) end date/thne data identifying a date and time at which a key becomes 

invalid; 

4) life-span data indicating a period of time over which the key is valid; 
20 5) key index data idoitifying the key from among a plurality of diSerent 

keys; 

6) hash identifier data indicating to the RDS a hash algorithm to be 
performed to generate &e hash data; 

7) encryption data indicating aa encryption model and/or algorithm used 
25 to encrypt and decrypt resource access right dat^ and 

8) format fields data indicating the number of fields in the signal 
requesting access to Hxe resource. 
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21 . A method characterized by the steps of: 

(a) recdvmg a signal requesting access to a resource, the signal having a 
secure universal resource locator (URL) witii secured resource access rig^t dat^ 

(b) extracting an Mecnet protocol (IP) address from the secured resource 
access tight data; 

(c) comparing the extracted IP address with the IP address included in a 
hypertext transport protocol (HTTP) message of the request signal; and 

(d) authenticating that the IP address of the soured resource access right 
data corresponds to the IP address of a device requesting access to the resource, based on the 
comparing of step (c). 

22. A method as claimed in claim 21 further characterized by the step of: 

(e) terminating the request signal if the autiienticating of step (d) indicates 
that the IP address of the secured resource access right data does not match the IP address 
extracted from the HTTP message. 

23. A method as claimed in claim 22 further characterized by the steps of: 

(e) if tbe authenticating of step (d) indicates that the IP address of the 
secure resource access right data matches the IP address of the device requesting access to 
the resource, obtaining a key corresponding to the IP address; 

(f) veri^g whether the key is valid based on data corresponding to the 
key in a secure content key database; 

(g) generating bash data based on at least the IP address, URL, and key; 

and 

(h) verifying that the hash data generated in the step matches the hash 
data included in the request signal received in &e step (a). 

24. A method as claimed in claim 23 further characterized by the steps of: 

(i) terminating the request signal if the verifying of the step Qx) indicates 
that the hash data generated in the step (g) does not match &e hash data included in the 
request signal received in the step (a). 
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25. A method as claimed in claim 23 further characterized by the steps of: 

(i) deteimining whether access to a resource is to be pro\dded to a device 
identified by the IP address, based on the resource access ri^ data included in the request 
signal; 

5 (j) retrieving the resource based on the URL included within the request 

signal; and 

(k) providing access to the resource to a device identified by the IP 
address if the determining of step (j) indicates that access to the resource is to be provided, 
based on the URL. 

10 26. A method as claimed in claim 25 fiirfher characterized by the steps of: 

(1) retrieving resource access right data from a database, 
the determining of step (j) based further on whether the ff address of the 
request signal is authorized to access the resource indicated by the URL of the request signal, 
based on the retrieved resource access right data, 
15 27, A method as claimed in claim 26 further characterized by the steps of: 

(m) terminating the request signal if the determining of the step Q) 
indicates that access to tibie resource is not to be provided based on the resource access right 
data included in the request signal 

28. A method as claimed in claim 26 wherein the resource access right data 
20 retrieved in the step (k) includes maximum reference data and reference count data, the 
method further characterized by the step of: 

(n) mcrementmg the reference count data to indicate that access to the 
resource has been requested by the request signal; 

(o) conjparing the incremented reference count data with the maximum 
25 reference count data; and 

(p) providing access to the resource if the comparing of step (o) indicates 
that the incremented reference count data does not exceed the maximum reference count 
da ta. 
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29. A method as claimed in claim 26 wherein fbe resource access right data 
retrieved in tiie step (k) includes life-span data for access to the resource indicated by the 
URL, the method further characterized by the steps of: 

(m) determining a time and date of receiving the request signal in step (a); 

(n) comparing the life-span data with the time and date of receiving the 
requesting signal; and 

(o) determining that the IP address of the request signal is authorized to 
access the resource, if the comparing of the step (n) indicates that the time and date of 
receiving the request signal is within the life-span data. 

30. A method as claimed in claim 29 wherein the resource access right data 
retrieved in the step (k) includes URL/resource provider identification data, the method 
further characterized by the step of: 

(p) retrieving the resource iSrom a resource provider subsystem via the 
Memet, based on the URiyresource provider identification data, the retrieved resource used 
to provide access to the resource in the step (k). 

31. A method as claimed in claim 30 wherein the resource access right data 
retrieved in the step (I) includes retrieval key data used to decrypt the resource retrieved in 
the step (p). 

32. A mediod characterized by file steps of: 

(a) receiving a signal requesting access to a resource, the request signal 
including a universal resource locator (UBL), secured resource access rig^t data, and an 
Internet protocol (IP) address of a device requesting access to the resource, and hash data; 

(b) veri^ing whether key data is valid based on data corresponding to the 
key data in a secure cont^t key database; 

(c) if the key data is verified as valid in step (b), g^erating hash data 
based on at least the IP address, URL, and &e key data; and 

(d) verifying fiiat the hash data genemted in the step (c) matches the hash 
data included in fiie request signal received in the step (a). 
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33 , A method as claimed in claim 32 furthcar characterized by the steps of: 

(e) tenninating the request signal if the verifying of the step (d) indicates 
that the hash data generated in the step (c) does not match the hash data included in flie 
request signal received in the step (a). 

5 34. A me&od as claimed in claim 33 further characterized by the steps of: 

(f) determining whether access to a resource is to be provided to a device 
identified by the IP addr^, based on the resource access right data included in the request 
signal; and 

(g) providing access to the resource to a device identified by the IP 
10 address if the determining of the step (f) indicates that access to the resource is to be 

provided. 

35. A method as claimed in claim 34 further characterized by the steps of: 

(h) retrieving resource access right data firom a database, 

the detennining of step (f) based fiirfher on whether the IP address of the 
15 request signal is authorized to access the resource indicated by the URL of tiie request signal, 
based on the retrieved resource access right data. 

36. A mefliod as claimed in claim 32 wherein the request signal received in step 
(a) includes key index data, the method furflier characterized by the step of: 

(e) retrieving the key data from the secure content key database using the 
20 key index data. 

37. A mettiod as claimed in claim 32 wherdn the step (b) is characterized by the 
substq)sof: 

(bl) detemiimng a date and time of receiving the request signal in the step 

(a); 

25 (b2) retrieving start date/dme data and end date/time date firom a database; 

(b3) comparing the date and time of the request signal witii the start 
date/time data and end date/ttrae data; and 

(b4) determining whether the key data is valid, based on the con?>aring of 

the step {b3). 
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38. A method as claimed in claim 32 wherein the step (b) is characterized by the 
substeps of: 

(b 1) determining a date and time of receiving the request signal in the step 

(a); 

5 (b2) retrieving life-span data from a database; 

(b3) comparing the date and time of receiving the request signal with the 
life-span data; and 

(b4) determining whether the key data is vahd, based on the comparing of 

the step (b3). 

10 39. A method characterized by the steps of: 

(a) receiving via the Bitemet a request signal including a universal 
resource locator (URL) mdicating a location of a resource, secured resource access right data 
indicating rights of a device to access the resource, and an Internet protocol (BP) address of 
the device; 

15 (b) determining whether access to the resource is to be provided to the 

device identified by the IP address, based on secured resource access right data included in 
the request signal; and 

(c) providing access to the resource to a device identified by the IP 
address if the detennining of the step (c) indicates that access to the resource is to be 

20 provided, 

40- A method as claimed in claim 39 further characterized by tiie step of: 

(d) terminating the request signal if the determining of the step (b) 
indicates that access to the device is not authorized. 

41 . A method as claimed in claim 39 wherein said step (c) is charactOTzed by the 
25 substep of transmitting the resource to flie device via the Internet 

42. A method as claimed in claim 39 further characterized by the step of: 

(d) authenticating the request signal if an Eatecnet protocol (E?) address of 
the URL in die request signal matches a UKL of ttie device contained in the resource access 
right data of the request signal. 



-58- 



WO02/1499J 



PCT/ljSOl/24398 



43, A method as claimed in claim 39 further <^ 

(d) retrieving resource access right data from a database, 
the determining of step (b) based further on \^ether the TP address of the 
request signal is auflioiized to access the resource indicated by the URL of tiie request signal, 
5 based on the retrieved resource access right data. 



10 in the received request signal; 

(g) determining whether the hash data generated in step (e) matches the 
hash data generated in the request signal, based on the comparing of the step (f), 

the access to the resource provided in step (c) if the determining of step (g) 
establishes that the hash data match. 
15 45. A method as claimed in claim 44 wherein the step (d) is characterized by the 



44. A method as claimed ia claim 39 jftirther characterized by the step of: 

(d) veri-fying validity of key data; 

(e) generating hash data based on at least the URL and tiie key data; 

(f) comparing the hash data generated in step (e) with hash data included 



substeps of: 



(dl) determioing a date and time of receiving the request signal in the step 



(a); 



20 



date/thne data 



(d2) retrieving start date/time data and &nd date/time date from a database; 
(d3) comparing the date and time of the request signal with the start 
and end date/time data; and 



(d4) determimng whether key data is valid, based on the comparing of the 



step(b3). 



steps (e) through (g) performed if Uie key data is detennined to be valid and 



25 not otherwise. 
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46. A method as claimed in claim 44 wherein the step (d) is characterized by the 
substeps of: 

(dl) detenmning a date and time of receiving the request signal in the stq) 

(a); 

5 (d2) retrieving Ufe-span data from a database; 

(d3) comparing the date and time of receiving the request signal with the 
life-span data; and 

(d4) detemnning whether key data is valid, based on the comparing of the 

step (b3), 

10 steps (e) through (g) performed if the key data is detennined to be valid and 

not otherwise. 

47. A system using the Ihtemet, the system characterized by: 

at least one web access device (WAD) executing a browser application, the 

WAD generating a signal requesting a web page document having a secure universal 
15 resource locator (URL), receiving the web page document having the secure URL, displaymg 

the web page document having the secure URL, and generating a signal requesting a resource 

indicated by the secure URL of the web page document; 

a resource provider subsjratem (EUPS) coupled to receive via the Memet the 

signal requesting the web page document from .tiie WAD, the RPS generating the secure 
20 URL to include resource access ri^t data defining restriction(s) of the WAD and/or us«r 

thereof to access the resource indicated by the URL, the RPS transmitting the web page 

document with the secure URL to the WAD; and 

at least one resource distribution subsystem (BDS) coupled to receive via the 

hrtemet the signal from the WAD requesting access to the resource, the RDS detecmining 
25 whether the resource access right data has been changed from establishment by the RPS, and, 

if the RDS determines that the resource access right data has not been changed, the RDS 

deteimining whether the WAD and/or user thereof is authorized to access tiie resource using 

the resource access right data, the RDS pOToitting access to the resource if the WAD and/or 

user thereof is authorized to access the resource. 
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48. A system as claimed in claim 47 wherein the resoraxie access right data 
includes at least one of: 

1) an authorized Internet protocol (IP) address or IP address range; 

2) life-span data indicating the life-span indicating a time period over 
5 which requests for accessing a resource are valid; and/or 

3) maximum reference data indicating a maximum number of times a 
web access device and/or user thereof can access a resource. 

49. A system as claimed in claim 47 wherein the hash data is generated by the 
RPS based on the URL, resource access right data, and key data, and the RDS stores the key 

10 data used by the RPS, the RDS verifying that the resource access right data has not changed 
from establishment by the RPS using the key data. 

50. A system as claimed in claim 47 wherein the key data includes a key and 
optionally at least one of: 

1) a second URL identifying the RPS; 
15 2) start date/time data identifying a date and time at which a key is valid; 

3) end date/time data identifying a date and time at which a key becomes 

invalid; 

4) life-span data indicating a period of time over which the key is valid; 

5) key index data identifying the key from among a plurality of diflFerent 

20 kej^; 

6) hash identifier data mdicating to the RDS a hash algorithm to be 
performed to generate file hash data; 

7) CTCiyption data indicating an encryption model and/or algorithm used 
to encrypt and decrypt resource access right data; and/or 

25 8) format fields data iiidicating tiiie number of fields in the signal 

requesting access to the resource. 

51. A server storing a secure universal resource locator (URL) goierator module 
executable by the server to generate a URL having secure resource access ri^t data defining 
restriction(s) on a web access device (WAD) and/or visgt thereof to access a resource 

30 indicated by the secure URL, the resource access right data secured by the server so that 
modification of the resource access right data can be detected. 
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52. A server as claimed ib claim 51 wherein the server stores a secure content key 
database having key data, and the server executes flie secure URL generator module to secure 
the resource access right data with the key data. 

53. A server as claimed in claim 51 wherein the server appends the key data to an 
5 Intemet protocol (IP) address of flie WAD requesting the web page document from the 

server, and hashes the key data and tiie TP address to generate hash data, the hash data 
combined with the URL and resource access right data to generate the secure URL. 

54. A server as claimed in claim 51 wherein the server uses the key data to 
encrypt the resource access right data and combines the encrypted resource access right data 

10 with the URL to produce the secure URL. 

55. A server as claimed in claim 51 wherem the server is characterized by a 
resource access ri^ database storing the resource access right data. 

56. A server as claimed in claim 51 wherein the server is chamcterized by an 
access right enforcer module, the server executing the access right enforcer module to 

15 deteraiine whether a resource is to be provided to another server in response to a request 
signal received from the other server via the Intemet, the server executing a secure caching 
module to transmit the resource to the other server for distribution if the resource access right 
data indicates that the oflier server is authorized to access the resource, and the server 
preventing access to the other server if the resource access rigiht data indicates the other 

20 server is not authorized to access the resource. 
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57. A server of a resource distribution subsystem (RDS) storing an access right 
©ttfoicer module executable by the server, ftie server executing the access right enforcer 
module in response to a signal &om a web access device (WAD) requesting access to a 
resource^ the request signal having a universal resource locator (URL) with secure resource 

5 access right data, the server executing the access right enforcer module using resource access 
right data to determine whether the resource access right data has been modified after its 
establishment by a resource provider subsystem (RPS), tiie server preventing access to the 
resource if the resource access right data has been modified after its establishment, the server 
further executing a secure caching module if the resource access right data has not been 
10 modified to provide acc^s to the resource if the WAD is determined by the server to have 
the right to access the resource based on the resource access right data, and the server 
blocldng access to the resource if the WAD is detemrined not to have the right to access the 
resource, 

58. A server as claimed in claim 57 wherein the request signal received by the. 
15 server fi:om the WAD includes an Internet protocol (IP) address, a universal resource locator 

(URL) indicating the location of the resource, and hash data, the server retrieving key data 
based on the IP address and/or URL, the server combining the key data with at least the IP 
address and/or URL, the server generating hash data based on the key data and IP address 
and/or URL, the server conqjaring the server-generated hash data with the hash data in the 
20 request signal, the server executing its secure caching module to provide access to the 
resource if the hash data matches, and the server blocking access to the resource if the hash 
data do not match. 

59. A server as claimed in claim 57 wherein the server retrieves date/time data 
fiom a secure content key database stored therem, the date/time data indicating a period of 

25 time over which ttie key data is valid, the server recording the date and time of receiving the 
requ^t signal at the serv^ and comparing the date and time of receipt of the request signal 
with tibie date/time data to determine whether the key data is valid, the server permitting 
further processing of the request signal if &e comparison indicates the key data is valid^ and 
the server terminating further processing of the request signal if the date/time data indicates 

30 the key data is not valid. 
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60- A serv^ as claimed in claim 59 wherein the server further retrieves from tihie 
secure content database life span data that the server uses in conjunction with the 
date/time data to detennine the period of time over which the key is valid so that date and 
tune of receiving Ihe request signal at the server can be compared by the server with tiie 
5 date/time data and life-span data to determine whether the key is valid. 
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